Set of standards for automated systems (KSAS)

The Unified System of Program Documentation (USPD) is a domestic set of standards for program documentation. In professional vernacular it is also called the “nineteenth guest,” which is not entirely correct, since we are talking about not one, but about 30 different regulatory and technical documents.

Basically, the ESPD standards contain requirements for the composition, content and execution of documents describing the program at different stages of its life cycle. In addition, several documents are devoted to the procedure for storing and updating documentation.

ESPD standards are practically devoid of a methodological component. They do not explain to the developer how to write documentation to make it useful, understandable, informative, convenient, etc. They only provide a list of document types and a list of first-level sections for each of them. True, it is said about each section what information should be presented in it.

The ESPD standards were adopted in the late 70s and have come to us in a form close to the original. They reflect the practice of departmental computer centers where large computers were operated. The interaction of a person with a computer system then was structured completely differently than it is now, and was carried out through bulky remote controls, punched cards and printouts, and for “mere mortals” solving applied problems, also through the mediation of qualified personnel. Do I need to explain at length how outdated these standards are by now? Suffice it to say that they are unaware of such common documents as the user manual and administrator manual.

And yet they continue to be actively used. Formally, the “nineteenth” has a modern alternative. Some ISO/IEC standards in the field of system and software engineering have been translated into Russian and adopted in Russia as national standards. But large customers, including government customers, are in no hurry to switch to them. This can be explained by their inertia (or loyalty to tradition, as you prefer), but only partly.

The fact is that each ESPD standard, with a small (three pages maximum) volume, is a set of rather formal and therefore easily verifiable requirements for a document or set of documentation. Strictly speaking, this does not prevent the documentation developer from writing correctly formatted nonsense. But since the ESPD clearly defines what the result should consist of and what it should look like, we can at least immediately reject a stack of paper that does not fit into these frameworks. This significantly simplifies the task of submitting and accepting documentation for both the customer and the contractor.

ISO/IEC standards, on the contrary, contain many reasonable rules of a substantive nature, but it is difficult to imagine a procedure for their formal verification. However, no one bothers to apply both sets of standards simultaneously; fortunately, they relate to different aspects of documentation and practically do not contradict each other.

Composition of regulatory and technical documents

Designation	Name
GOST 19.001-77	General provisions
GOST 19.002-80	Unified system of program documentation. Schemes of algorithms and programs. Execution Rules
GOST 19.004-80	Unified system of program documentation. Terms and definitions
GOST 19.005-85	Unified system of program documentation. P-schemes of algorithms and programs. Conventional graphic designations and execution rules
GOST 19.101-77	Unified system of program documentation. Types of programs and program documents
GOST 19.102-77	Unified system of program documentation. Development stages
GOST 19.103-77	Unified system of program documentation. Designation of programs and program documents
GOST 19.104-78	Unified system of program documentation. Basic inscriptions
GOST 19 105-78	Unified system of program documentation. General requirements for program documents
GOST 19.106-78	Unified system of program documentation. Requirements for printed program documents
GOST 19.201-78	Unified system of program documentation. Terms of reference
GOST 19.202-78	Unified system of program documentation. Specification. Requirements for content and design
GOST 19.301-79	Unified system of program documentation. Test program and methodology. Requirements for content and design
GOST 19.401-78	Unified system of program documentation. Program text. Requirements for content and design
GOST 19.402-78	Unified system of program documentation. Description of the program
GOST 19 403-79	Unified system of program documentation. List of original holders
GOST 19.404-79	Unified system of program documentation. Explanatory note. Requirements for content and design
GOST 19.501-78	Unified system of program documentation. Form. Requirements for content and design
GOST 19.502-78	Unified system of program documentation. Description of application. Requirements for content and design
GOST 19.503-79	Unified system of program documentation. System Programmer's Guide. Requirements for content and design
GOST 19.504-79	Unified system of program documentation. Programmer's Guide
GOST 19.505-79	Unified system of program documentation. Operator's manual. Requirements for content and design
GOST 19.506-79	Unified system of program documentation. Description of the language. Requirements for content and design
GOST 19.507-79	Unified system of program documentation. List of operational documents
GOST 19.508-79	Unified system of program documentation. Maintenance Manual. Requirements for content and design
GOST 19.601-78	Unified system of program documentation. General rules for duplication, accounting and storage
GOST 19.602-78	Unified system of program documentation. Rules for duplication, accounting and storage of printed program documents
GOST 19.603-78	Unified system of program documentation. General rules for making changes
GOST 19.604-78	Unified system of program documentation. Rules for making changes to printed program documents

Acquisition of standards

Establishing interrelated rules for the development, design and circulation of programs and program documentation.

The ESPD standards establish requirements governing the development, maintenance, production and operation of programs, which ensures the ability to:

• unification of software products for mutual exchange of programs and the use of previously developed programs in new developments;
• reducing labor intensity and increasing the efficiency of development, maintenance, production and operation of software products;
• automation of production and storage of program documentation.

Program maintenance includes analysis of the functioning, development and improvement of the program, as well as making changes to it in order to eliminate errors.

Since the ESPD is a set of GOSTs, currently its application on the territory of the Russian Federation is only advisory in nature, that is, the ESPD is applied on a voluntary basis (unless otherwise provided by an agreement, contract, individual laws, court decision, etc.).

Encyclopedic YouTube

1 / 3

Calculation of a panel building

Webinar: New features of Advance Steel 2018 for designing metal structures

Master class #2 “Autodesk Fusion 360 - a unified environment for innovative design

Subtitles

Classification

ESPD standards are divided into groups shown in the table.

List of standards included in the ESPD

• GOST 19.001-77. ESPD. General provisions.
• GOST 19.002-80. ESPD. Schemes of algorithms and programs. Execution rules. - Replaced by GOST 19.701-90
• GOST 19.003-80. ESPD. Schemes of algorithms and programs. Symbols are conventional graphic. - Replaced by GOST 19.701-90
• GOST 19.004-80. ESPD. Terms and definitions. - Replaced by GOST 19.781-90
• GOST 19.005-85. ESPD. P-schemes of algorithms and programs. Conventional graphic designations and execution rules.
• GOST 19.101-77. ESPD. Types of programs and program documents.
• 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 specifications. 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. Requirements for content and design.
• GOST 19.401-78. ESPD. Program text. Requirements for content and design.
• GOST 19.402-78. ESPD. Description of the program.
• GOST 19.403-79. ESPD. List of original holders.
• 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. Requirements for content and design.
• GOST 19.505-79. ESPD. Operator's manual. Requirements for content and design.
• GOST 19.506-79. ESPD. Description of the language. Requirements for content and design.
• GOST 19.507-79. ESPD. List of operational documents.
• GOST 19.508-79. ESPD. Maintenance Manual. Requirements for restraint and form.
• GOST 19.601-78. ESPD. General rules for duplication, accounting and storage.
• GOST 19.602-78. ESPD. Rules for duplication, accounting and storage of printed program documents.
• GOST 19.603-78. ESPD. General rules for making changes.
• GOST 19.604-78. ESPD. Rules for making changes to printed program documents.
• GOST 19.701-90 (ISO 5807-85). ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules.
• GOST 19781-90. Software for information processing systems. Terms and definitions.

Unified system of program documentation(ESPD) - a set of state standards , establishing interrelated rules for the development, design and circulation of programs and program documentation. The ESPD standards establish requirements governing the development, maintenance, production and operation of programs, which ensures the ability to:

Unification of software products for mutual exchange of programs and the use of previously developed programs in new developments;

Reducing labor intensity and increasing the efficiency of development, maintenance, production and operation of software products;

Automation of production and storage of program documentation.

Program maintenance includes analysis of the functioning, development and improvement of the program, as well as making changes to it in order to eliminate errors.

The rapid increase in the complexity and size of modern software packages, with a simultaneous increase in the responsibility of the functions performed, has sharply increased the requirements from customers and users for their quality and safety of use.

A proven means of ensuring high efficiency and quality of functioning of programs and software systems are international standards developed with the participation of representatives of leading companies in the industry.

As the use and complexity of information systems increases, errors or insufficient quality of programs can cause damage that significantly exceeds the positive effect of their use.

GOST 28195-89 establishes general provisions for assessing the quality of software (PS) of computer technology supplied through funds of algorithms and programs (FAP), the nomenclature and applicability of software quality indicators. Quality assessment A PS is a set of operations that include selecting a range of quality indicators for the assessed PS, determining the values ​​of these indicators and comparing them with the basic values.

According to GOST 28195-89, quality assessment is carried out at all stages of the substation life cycle at:

Planning of PS quality indicators;

Quality control at individual stages of development (technical specifications, technical design, working draft);

Quality control during the PS production process;

Checking the effectiveness of PS modification at the maintenance stage.

Quality assessment is carried out by specialists from organizations: developer - at the stages of software development; fund holder - at the stages of acceptance of the software into the fund; testing centers and PS certification centers - at the stages of testing and implementation; manufacturer - at the stages of PS replication; user - at the stages of implementation, maintenance and operation of the software.

The main tasks to be solved when assessing the quality of the software:

Quality level planning;

Monitoring quality indicator values ​​during development and testing;

Operational control of a given quality level;

Selection of basic samples by subclasses and groups;

Methodological guidance in the development of normative and technical documents for quality assessment.

Methods for determining PS quality indicators vary:

By methods of obtaining information about the PS - measuring, registration, organoleptic, calculation;

According to the sources of obtaining information - traditional, expert, sociological.

Measuring The method is based on obtaining information about the properties and characteristics of the PS using tools. For example, using this method, the volume of the program is determined - the number of lines of source text of programs and the number of lines of comments, the number of operators and operands, the number of executed statements, the number of branches in the program, the number of entry (exit) points, the execution time of a program branch, reaction time and other indicators.

Registration The method is based on obtaining information during testing or operation of the substation, when certain events are recorded and counted, for example, the time and number of failures and failures, the time of transfer of control to other modules, the start and end time of work.

Organoleptic the method is based on the use of information obtained as a result of analysis of the perception of the senses (vision, hearing), and is used to determine such indicators as ease of use, efficiency, etc.

Calculated The method is based on the use of theoretical and empirical dependencies (in the early stages of development), statistical data accumulated during testing, operation and maintenance of the substation. Using the calculation method, the duration and accuracy of calculations, reaction time, and required resources are determined.

Determination of the values ​​of PS quality indicators using the expert method is carried out by a group of expert specialists competent in solving this problem, based on their experience and intuition.

The expert method is used in cases where the problem cannot be solved by any other existing method or other methods are much more labor-intensive. The expert method is recommended to be used when determining indicators of clarity, completeness and accessibility of program documentation, ease of learning, and structure.

Sociological methods are based on the processing of special questionnaires. The domestic standard GOST 28195-89 defines the hierarchical structure, nomenclature and content of software quality concepts. At the top level, six characteristics are identified: reliability, correctness, ease of use, efficiency, versatility and maintainability, which are detailed at the second level with 19 complex indicators. At the third level, further detail contains more than 200 evaluation elements. It is recommended to select the composition of the indicators used depending on the purpose, functions and stages of the software tool’s life cycle. However, there are no methods for assessing indicators.

The international standard ISO / IEC 14598-1-6:1998-2001 is devoted to the methodology for assessing the quality characteristics of finished PCBs at various stages of the life cycle. Since the entry into force of GOST 28195-89, significant changes have occurred in many aspects of social life, including significant changes in economic and legal relations in the field of development and operation of software. For example, in the field of commercial software products, the fund holder has disappeared, and the developer and manufacturer are usually the same legal entity. In market conditions, the developer is interested in ensuring the quality of its products throughout their entire life cycle. In addition, the procedure for product certification has changed.

Alienation rights to a computer program are exercised on the basis of a contract. The party to the agreement (developer) on the alienation of the exclusive right to the alienated program, which transfers or undertakes to transfer the exclusive right belonging to it, is called the copyright holder. The party accepting under the agreement on the alienation of the exclusive right to the alienated program is called the acquirer.

Under an agreement on the alienation of an exclusive right, the copyright holder transfers or undertakes to transfer the exclusive right belonging to him to the acquirer in full (clause 1 of Article 1234 and Article 1285 of the Civil Code of the Russian Federation).

An agreement on the alienation of an exclusive right does not legally require an indication of the period and territory, since the transfer of the exclusive right to a computer program in full implies a transfer for the entire period of validity of the exclusive right without limiting the territory.

Under an agreement on the alienation of an exclusive right, the acquirer undertakes to pay the right holder the remuneration stipulated by the agreement, unless otherwise provided by the agreement.

Since an agreement on the alienation of the exclusive right to a registered computer program is subject to state registration, then, according to paragraph 4 of Article 1234 of the Civil Code of the Russian Federation, the exclusive right to such results passes from the copyright holder to the acquirer at the time of state registration of this agreement.

Under a license agreement, one party - the author or other copyright holder (licensor) grants or undertakes to provide the other party (licensee) with the right to use this work within the limits established by the agreement (not in full). A license agreement granting the right to use a computer program is not subject to mandatory registration. The program developer in the contract may allow the other party to use the program under certain conditions (terms, territory, rental, etc.). In this case, the program remains inalienable from its author.

The most common questions that arise during the software development process are:

Lack of transparency. At any given time, it is difficult to say what state the project is in and what its percentage of completion is. This problem arises when there is insufficient planning of the structure (or architecture) of a future software product, which is most often a consequence of the lack of sufficient funding for the project: the program is needed, how long the development will take, what are the stages, can some stages be eliminated or saved - the consequence of this process is that the design phase is shortened.

Lack of control. Without an accurate assessment of the development process, work schedules are disrupted and established budgets are exceeded. It is difficult to estimate the amount of work completed and remaining. This problem arises at the stage when a project, more than half completed, continues to be developed after additional funding without assessing the degree of completion of the project.

Lack of tracing.

Lack of monitoring. The inability to observe the progress of the project does not allow monitoring the progress of development in real time. Using tools, project managers make decisions based on real-time data. This problem arises in conditions where the cost of training management to master the tools is comparable to the cost of developing the program itself.

Uncontrolled changes. Consumers are constantly coming up with new ideas about software being developed. The impact of changes can be significant to the success of the project, so it is important to evaluate proposed changes and implement only those that are approved, controlling this process using software tools. This problem arises due to the reluctance of the end consumer to use certain software environments. For example, when creating a client-server system, the consumer makes demands not only on the operating system on the client computers, but also on the server computer.

Insufficient reliability. The most difficult process is finding and correcting errors in computer programs. Since the number of errors in programs is unknown in advance, the duration of debugging programs is also unknown in advance and there is no guarantee that there will be no errors in programs. It should be noted that using an evidence-based approach to software design makes it possible to detect errors in a program before it is executed. This problem occurs when you choose the wrong development tools. For example, when trying to create a program that requires high-level tools using low-level tools. For example, when trying to create automation tools with a DBMS in assembler. As a result, the source code of the program turns out to be too complex and difficult to structure.

Lack of guarantees for the quality and reliability of programs due to the lack of guarantees that there will be no errors in the programs up to the formal delivery of the programs to customers. This problem is not a problem unique to software development. Quality assurance is the problem of choosing a supplier of a product (not a product).

Legal, economic and other issues of software creation The regulatory framework for software must include legal norms governing:

Ownership rights to the software and information stored in it;

Methods for obtaining information to fill in the relevant databases;

Rights of legal entities and individuals to information;

Ways to protect the rights of the state and consumer of information;

Legal relations (rights, obligations and responsibilities) between persons maintaining the software;

The legal force of information on media and documents used in the operation of the software.

The main provisions that define the economic basis for creating software are as follows:

Financing of work to create and ensure the functioning of software from federal budgetary funds allocated for public administration, from the budgetary funds of departments (organizations, institutions) - potential users of information and who have entered into cooperation with the Ministry of State Property of Russia to create state-owned software (GS), as well as for extrabudgetary financial resources account;

Monitoring the use of budget funds allocated for the creation and development of software;

Providing information support benefits to organizations involved in the management of state property, as well as software investors;

Granting the right to the Ministry of State Property of Russia to set prices for specific information products and services;

Exercising state control over prices for a certain period or for a certain type of information product;

Establishment by the state of prices for information products (services) carried out under state orders and at the expense of budgetary funds.

At the same time, organizational issues regulating the interaction of workers with technical means and among themselves in the process of developing and operating software are resolved.

The term “intellectual property” was occasionally used by theorists - lawyers and economists in the 18th and 19th centuries, but came into widespread use only in the second half of the 20th century, in connection with the establishment of the World Intellectual Property Organization (WIPO) in Geneva in 1967. According to WIPO's founding documents, "intellectual property" includes rights relating to:

Literary, artistic and scientific works:

Performing activities of artists, sound recordings, radio and television broadcasts:

Inventions in all areas of human activity:

Scientific discoveries;

Industrial designs;

Trademarks, service marks, trade names and trade names;

Protection against unfair competition;

As well as all other rights related to intellectual activity in the industrial, scientific, literary and artistic fields.

Later, WIPO's scope of activities included exclusive rights related to geographical indications, new plant varieties and animal breeds, integrated circuits, radio signals, databases, and domain names.

Each object of intellectual property has the property of individuality, since during its creation the achievements of human intelligence, individual properties of thinking and perception were used. An object of intellectual property is always in close interaction with objects of property law and is always embodied in material objects, but exists separately, which allows the use of an object of intellectual property regardless of its material carrier. Special social relations that develop regarding an object of intellectual property are a separate object of legal regulation.

The gradual change in the state's attitude towards the results of intellectual activity, which are increasingly acquiring the features of a product created to function on the market, is also evidenced by the introduction of legal protection for computer programs.

Software is protected as an object of intellectual property by law. In relation to this type of object, there is a special legal regulation introduced by the Law “On the Legal Protection of Programs for Electronic Computers and Databases,” which came into force on October 20, 1992.

Self-test questions

1. What quality indicators determine programs?

2. What is a software product?

3. What is meant by software life cycle?

4. For what purpose are software specifications defined?

5. What are the stages of software development?

7. What is meant by verification and certification of a software product?

8. What is the essence of the modular structure of software?

9. What is the difference between standalone and integrated software debugging?

10. What is program portability?

11. What properties do open systems have?

12. What is meant by the Unified System of Program Documentation?

13. How is the alienated program formalized?

14. What legal law protects intellectual property on computer programs?

Literature

1. Ivanova G.S. Programming technology. - M.: KnoRus, 2011. - 333 p.
2. Kamaev V.A. Programming technologies. - M.: Higher School, 2006. - 454 p.
3. Orlov S.A. Software development technology. - St. Petersburg: Peter, 2004. 526 p.
4. Rudakov A.V. Software development technology. - M.: Academy, 2010. 207 p.
5. http://sp.cmc.msu.ru/info/37techprog.htm - programming technology.
6. http://www.twirpx.com/file/27591/ - programming technology, lectures.
7. http://www.intuit.ru/department/se/introprogteach/1/3.html - program life cycle.
8. http://www.pervviurok.ru/Info/Internet Development/gl11/gl11.html - debugging modules.
9. http://citforum.ru/database/articles/art 19.shtml - open systems.
10. http://www.mini-soft.ru/book/tech prog/ - programming technology.
11. http://www.labfor.ru/?act=metod&target=metod leso1 1 - programming environment.

ESPD – refers to complex systems of general technical standards

ESPD is a system of interstate standards of the CIS countries operating in the Russian Federation, based on an interstate agreement on standardization. ESPD standards cover that part of the documentation that is created during the development of software and is mostly associated with documenting the functional characteristics of software. ESPD standards are advisory in nature

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

ESPD standards establish requirements governing the development, support, production and operation of programs, which ensures the ability to:

1. Unification of software products for mutual exchange of programs and the use of previously developed programs in new developments

2. Reducing labor intensity and increasing the efficiency of development, maintenance, production and operation of software products

3. Automation, production and storage of program documentation

Program maintenance includes analysis of the functioning, development and improvement of the program, as well as making changes to it in order to eliminate errors

The rules and regulations established in the ESPD standards apply to programs and software documentation for subtractive machines, complexes and systems, regardless of their purpose and scope of application

The ESPD includes:

1. Fundamental and organizational and methodological standards

2. Standards defining the forms and content of program documents used in data processing

3. Standards that ensure automation of the development of program documents

The development of organizational and methodological documentation that defines and regulates the activities of organizations for the development, maintenance and operation of programs should be carried out on the basis of ESPD standards

ESPD standards are divided into classification groups

ESPD standards are designated as follows:

GOST 19.001-77

19 – standards belonging to the ESPD

0 – General provisions

77 – year of approval

GOST 19.503-79- system programmer's guide. Requirements for content and design. Abstract and content are required. The system programmer's manual should contain the following sections:

1. General information about the program

Purpose and functions of the program and information about the hardware and software that ensures the execution of this program

2. Program structure

Information about the structure of the program, its components, connections between components and connections with other programs

3. Setting up the program

Description of steps to configure the program for a specific application (adjustment to the composition of hardware, selection of functions, etc.)

4. Checking the program

Description of testing methods that allow us to give general conclusions about the performance of the program (test examples, running methods, results)

5. Additional features

Description of additional sections, program functionality and methods for selecting them

6. Message to the system programmer

Texts of messages issued during program execution, description of their content and actions that must be performed on these messages

7. List of documents

Depending on the specifics of the document, it is possible to combine individual sections and introduce new ones. In justified cases, it is permissible not to include the “additional features” section, and in the names of sections – to omit the word program, or replace it with the name of the program

The appendix to the system programmer's manual may contain additional materials (examples, illustrations, tables, graphs...)

GOST 19.504-79- programmer's guide. Requirements for content and design. Abstract and content are required. The programmer's manual should contain the following sections:

1. Purpose and conditions of use

Purpose and functions, conditions necessary for implementation (RAM volume, requirements for the composition and parameters of peripheral devices, software requirements)

2. Program characteristics

Description of the main characteristics and features of the program (time characteristics, operating mode, means of monitoring the correct execution and self-healing of the program)

3. Access to the program

Description of program call procedures (methods of transferring control and data parameters)

4. I/O data

Description of the organization of I/O information and, if necessary, its coding

5. Message

Texts of messages issued to the programmer or operator during program execution, a description of their content and actions that must be performed on these messages

6. List of documents

Depending on the specifics of the document, it is possible to combine individual sections and introduce new ones. The appendix to the programmer's manual may contain additional materials (examples, illustrations, tables, graphs...)

GOST 19.505-79- operator's manual. Requirements for content and design. Abstract and content are required. The operator's manual should contain the following sections:

1. Purpose of the program

Information about the purpose and information sufficient to understand the functions of the program and its operation

2. Conditions for program execution

Conditions necessary for program execution (minimum and (or) maximum hardware and software)

3. Execution of the program

The sequence of operator actions that ensure loading, launching and terminating the program (a description of the functions, format and possible options of commands with which the operator loads and controls the execution of the program, as well as the program’s responses to these commands should be provided

4. Message to the operator

Texts of messages issued during program execution, description of their content and corresponding operator actions (operator actions in case of failure, possibility of restarting the program...)

5. List of documents

Depending on the specifics of the document, it is possible to combine individual sections and introduce new ones. It is allowed to illustrate the contents of sections with explanatory examples, tables, diagrams and graphs. In the appendix to the operator's manual it is allowed to include various materials that are inappropriate to include in sections of the manual

And software documentation.

The ESPD standards establish requirements governing the development, maintenance, production and operation of programs, which ensures the ability to:

• unification of software products for mutual exchange of programs and the use of previously developed programs in new developments;
• reducing labor intensity and increasing the efficiency of development, maintenance, production and operation of software products;
• automation of production and storage of program documentation.

Program maintenance includes analysis of the functioning, development and improvement of the program, as well as making changes to it in order to eliminate errors.

List of standards included in the ESPD

• GOST 19.001-77. ESPD. General provisions.
• GOST 19.003-80. ESPD. Schemes of algorithms and programs. Symbols are conventional graphic.
• GOST 19.005-85. ESPD. P-schemes of algorithms and programs. Conventional graphic designations and execution rules.
• GOST 19.101-77. ESPD. Types of programs and program documents.
• 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 specifications. 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. Requirements for content and design.
• GOST 19.401-78. ESPD. Program text. Requirements for content and design.
• GOST 19.402-78. ESPD. Description of the program.
• GOST 19.403-79. ESPD. List of original holders.
• 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. Requirements for content and design.
• GOST 19.505-79. ESPD. Operator's manual. Requirements for content and design.
• GOST 19.506-79. ESPD. Description of the language. Requirements for content and design.
• GOST 19.507-79. ESPD. List of operational documents.
• GOST 19.508-79. ESPD. Maintenance Manual. Requirements for content and design.
• GOST 19.601-78. ESPD. General rules for duplication, accounting and storage.
• GOST 19.602-78. ESPD. Rules for duplication, accounting and storage of printed program documents.
• GOST 19.603-78. ESPD. General rules for making changes.
• GOST 19.604-78. ESPD. Rules for making changes to printed program documents.
• GOST 19.701-90 (ISO 5807-85). ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules.

See also

Links

Wikimedia Foundation. 2010.

See what the “Unified Software Documentation System” is in other dictionaries:

- (ESKD) a set of state standards that establish interrelated rules, requirements and norms for the development, execution and circulation of design documentation developed and applied at all stages of the life cycle ... Wikipedia

system- 4.48 system: A combination of interacting elements organized to achieve one or more specified goals. Note 1 A system can be considered as a product or the services it provides. Note 2 In practice... ...

RD 153-34.1-35.521-00: Guidelines. Composition and maintenance of operational documentation in the workshops of automated process control systems (TAI) of thermal power plants- Terminology RD 153 34.1 35.521 00: Guidelines. Composition and maintenance of operational documentation in the workshops of automated process control systems (TAI) of thermal power plants: 1. Automated process control system (APCS) System... ... Dictionary-reference book of terms of normative and technical documentation

- (EIS) is a set of organizational, technical, software and information tools combined into a single system for the purpose of collecting, storing, processing and issuing the necessary information intended to perform the functions... ... Wikipedia

ESPD- Unified system of program documentation... Dictionary of Russian abbreviations

The Unified System of Program Documentation (USPD) is a set of state standards that establish interrelated rules for the development, execution and circulation of programs and program documentation. The ESPD standards establish requirements... ... Wikipedia

- (TOR, terms of reference) the source document for the development and testing of the product. Contents 1 Concept of TK 2 Place of TK in the structures ... Wikipedia

operational documentation- 30 operational documentation Documentation for formwork, made in accordance with the requirements of GOST 2.601 95 (passport, operating instructions, etc.)