LLC "Technical documentation. Application of state standards in the design of information systems
Introduction
In this standard, the terms are arranged in a systematic order that reflects the system of concepts in the field of electronic information exchange. Terms are grouped into subsections that combine several thematically related terms.
There is one standardized term for each concept.
Standardized terms are in bold font, their short forms represented by the abbreviation are in light font, and synonyms are in italic font in brackets.
Part of a verbose term that may be omitted in its short form is shown in parentheses in light font.
In square brackets after the definition is the designation of the standard in accordance with which the definition of the introduced term is given.
In some cases, after the term the necessary clarifications of the defined term are given (in square brackets).
In the body of this standard, terms borrowed from other standards are enclosed within a box. In square brackets are references to these standards indicating the serial number in the bibliography.
The following terms are used in the appendices to this standard:
Legal force of the document, documentation rules, document flow (GOST R 51141-98);
Relationship open systems, basic reference model, level, presentation level, application level (GOST R ISO/IEC 7498-1-99);
Byte, digit, digital data, letter, sign, number, information (ISO/IEC 2382-1-93).
6.4 ElD type
NOTE The following protocol definitions are equivalent in the context of this standard. The second of them is traditional, but too detailed in this context.
document: Information and related media.
document: A uniquely designated block of information for human use, such as a report, specification, manual, or book.
document: Structured information, directly or indirectly intended for human consumption, that can be transmitted, stored, retrieved, and processed through institutional applications.
Note - This definition is also used in GOST R ISO/IEC 10166, GOST R ISO/IEC 10740.
document(documentation element): Targeted information intended for a specific audience, located on a specific medium (eg, book, disk, quick reference card) in a specified format.
document: A structured body of information, intended to be visually perceived, that can be exchanged as a unit between users and/or systems.
document: A collection of information that is processed as a whole. Documents are classified according to specific document types.
NOTE In this standard, this term almost always means (without loss of precision) an SGML document.
electronic document: A document on a machine-readable medium that requires computer technology to use.
electronic document(DE): Information object consisting of two parts:
Details containing identifying attributes (name, time and place of creation, information about the author, etc.) and an electronic digital signature;
If necessary, DE can take on various forms of visual display: on a screen or paper.
A.2 Conceptual model adopted in ISO 2382-, ISO 14662, ISO/IEC 10746-1
The existence of the above (but not exhaustive) examples of inconsistent definitions of the same concept is due, first of all, to the fact that each of the above definitions is limited to the scope of application of a particular standard and is focused on solving one particular document flow problem. The terminology of this standard is consistent with the approaches adopted in the basic standards for terminology in the field of IT (standards of the ISO 2382 series), electronic exchange data (ISO 14662) and information processing in distributed systems(ISO/IEC 10746 series standards).
Adopted in these standards modern approach to the IT specification is based on the separation of two different aspects of phenomena: social (in this case, purpose, information, document, etc.) and technological (in this case, media, format, data, etc.). Standards establish rules to ensure harmonization of issues related to social aspects electronic document management(business information, contracts, agreements and rules adopted between organizations, including issues of confidentiality, reliability, etc.) and IT issues themselves ( functionality, service interfaces, protocols, etc.).
The concepts introduced in this standard reflect the social nature of the concept of “document” and make it possible to connect the document with its implementation by IT methods based on ISO 14662 and ISO/IEC 10746 series standards.
Appendix B
A document can exist in the form of a material object or process that acts as an intermediary of information interaction.
The division of documents into analog, discrete, and electronic is determined by the technologies used. The difference between them is a difference in the environment of existence, and therefore in the form of their existence and representation. Moreover, the same document, regardless of its form, reflects the same social relations and performs the same social functions.
Note - In some cases, the requirements for a document limit the possible forms of existence of the document. For example, a banknote can only exist in paper form (an analog document) and in a single copy.
An analog document is an object of an analog environment. For example, a traditional text paper document is classified as an analog document. The concept of A&D includes all traditional forms of presenting documents on analogue media: paper, photo and film, etc. Analogue form of representation can be converted into discrete form using digitization (term).
The concept of “electronic document” refers to data processing using IT. Characteristic feature IT is the transformation of processed data from one form of representation (implementation, term) to another and, possibly, the simultaneous existence of several equivalent representations of the same data. The main method of data processing in IT is digital processing. An electronic document in digital form is a discrete document.
Due to the laws of the electronic environment, electronic data can exist in this environment only as a set of equivalent implementations, each of which can be transformed into another based on formal rules, and all of them display the same information. Identification of ElD, i.e. set of equivalent implementations, is possible based on any subset, including one implementation.
Any work with an electronic document is a transformation of one implementation into another, and several implementations can exist simultaneously. For example, when playing an ELD stored in a file on disk on a monitor screen, at least two implementations exist simultaneously: the file on disk and the image on the screen. In addition, depending on the hardware and software architecture, there may be: a file in random access memory computer, file in the memory of a video device, file in the memory of a disk drive, data streams in channels connecting different devices, etc. All these implementations are equivalent, because represent the same document. The properties of these implementations, relationships with the environment of existence and the rules for converting them into each other are determined by the laws of the electronic environment.
Just as in the document effectiveness sector there are requirements for the document, so in the electronic data effectiveness sector there are requirements for the implementation of electronic data in electronic and digital environments. The specificity of the requirements for (implementation) of the electronic document in relation to the general requirements for the document in its sector of effectiveness is determined by the laws of the environment of its existence.
The latter, in particular, establish that in the electronic environment, electronic data can only exist in the form of many interconnected implementations. Interconnectedness of implementations means that one implementation can be obtained from another as a result of a formally defined transformation. Each of these implementations can only exist in a part of the electronic environment. The laws of this environment establish restrictions on the choice of the permissible sector of implementation effectiveness, which is a subsector of the effectiveness of eD.
Among the implementations, a subset of reproductions is highlighted due to their special significance for a person - the possibility of their direct perception. In the above example, only the implementation of the ElD on the monitor screen is available for direct perception, and it is representative of the entire set of implementations of this ElD, incl. file on your computer disk.
The EL effectiveness sector is a union of sectors of the effectiveness of its implementations, in each of which uniform (within the sector) rules for processing and converting data are established.
The EL effectiveness sector is divided into subsectors “vertically” and “horizontally”. The vertical division is determined by the levels of the VOS model (GOST R ISO/IEC 7498-1), which correspond, in particular, to different degrees of detail in the description of the electronic environment. Horizontal division is determined by the presence different areas data processing. Data processing areas are individual devices for processing, storing and transmitting data. Realizations exist in separate cells resulting from this division. The transformation of one implementation into another, located in an adjacent cell, is carried out on the basis of formal rules (algorithms) and is reversible.
Note - Several devices can be considered as a whole, as combined into one processing area, the internal structure of which is not significant for this consideration. In particular, any data processing system is such an area consisting of several devices; at that level of consideration at which the details of the internal structure of the system are not of interest, the system is considered as a single whole.
In a social environment, a document must have the above properties that are necessary for the document to execute it. social role. The presence of these properties in a document is formulated in the form of requirements of the social environment, and the fulfillment of these requirements must be ensured by technical means. Requirements for the implementation of a document are derived from the laws of the technological environment and social requirements for the document.
The fixity of a document means that the message it conveys fixes some fact, event, relationship, and the meaning of this message does not depend on the material implementation (informally speaking, the meaning of the document is “fixed”). For AnD, fixedness means, for example, that the content (meaning) of the law should not depend on the typographical execution. For ELD, fixedness means, for example, that the content (meaning) of the law should not depend on its implementation - in the form of a file on a disk, an image on a monitor, or a flow of signals on a network.
Thus, the fixedness of the document does not mean the fixedness of the presentation form, but must be ensured by the selected presentation form(s) (sections , - ) and the corresponding processing processes (sections , and ). In the electronic environment, the social requirement of fixity exists in the form of a formal requirement to preserve a certain invariant during work with a document (which depends on the type of document and the technology used).
The accessibility of a document implies that it may contain individual elements (parameters), the values of which can be measured. For eD, availability is based on usage established formats(sections , - ), which define the structure of specific implementations.
The values of the parameters included in the integrity requirements can be specified in regulatory documents or can be obtained in a given way from the values of some document presentation parameters at some previous point in time. For ELD, integrity is ensured based on application established methods processing implementations, i.e. based on technology that preserves given parameters unchanged (sections , and ).
Note - Requirements for electronic data implementation parameters, compliance with which ensures the availability and integrity of the document, depend on the social requirements for the document. In the simplest case, it may be sufficient to obtain a visual reproduction of the electronic document (accessibility) and visually verify that the resulting text matches a certain sample (integrity). With more stringent social requirements for a document, it is necessary to ensure, for example, the availability and accessibility of security attributes and their compliance with established technical requirements.
The legitimacy of a document means that when working with it, only valid operations were used in an acceptable sequence. The legitimacy of ELD is ensured by protection methods.
The ability to demonstrate a document is necessary, and the actual demonstration is sufficient condition for the document to fulfill it social function. The place, time and other conditions of the demonstration may not be determined in advance, but must be determined at the time of the demonstration itself with an accuracy that ensures the possibility of repeated demonstration under similar conditions. The parameters (characteristics) that can be measured for a given implementation and the methods for measuring them must be pre-established for this type of implementation.
The type of document is determined by its functional purpose, which also determines the technological requirements for the material implementation of the document. In particular, the concepts of “copy of a document”, “certified copy of a document”, “duplicate of a document” according to GOST R 51141 refer to the functional purpose of a document in the social environment (through the concept “ legal force"), do not contain indications of technical implementation and should be considered as definitions of document types. In the case of an analog (paper) document, the creation of a new type of document (“copy”) coincides with the technological procedure of copying. In the case of electronic data, due to the specifics of data processing in the electronic environment, a document exists in the form of a set (term) of equivalent implementations (term 5.3.1), and any work with a document, incl. viewing it on the display screen consists of continuously creating these implementations (), i.e. in “copying” a document. In this case, the technological operation of copying does not lead to the creation of a new type of document (“copy”), but only to the creation of a new implementation equivalent to any other implementation of the electronic document.
In the digital environment, information is represented as a bit string - a set of zeros and ones. Understanding this information (its interpretation) belongs to the sphere of human activity. In the digital (and electronic) environment itself, there is no “understanding” of information. In this environment, only formal rules for data processing can be specified (by humans).
Otherwise, data can be defined as the implementation of electronic data in the digital environment. Data consists of an ordered sequence of blocks - elements. For each element, its type must be specified, allowing the data to be interpreted (understood). The type of a data element is not a property of the data, but is prescribed by humans in standards, specifications, and other technical documents. The same data element can be interpreted different ways, i.e. it may be prescribed several different types. For example, a sequence of 16 bits can be interpreted as binary, octal, decimal, hexadecimal, character (letter) or machine instruction code. Each of these interpretations has its own way of reproducing data, its own set of permissible operations and values. The data type can be used to identify the hardware, software, or other equipment needed to reproduce or manipulate the data.
Part of the interpretation of data, represented in the form of formal rules, can be entered into a computer, and also presented in the form of a formalized algorithm. This does not mean that the computer will "understand" the information. It will only execute the given commands.
Note - Data processing rules (algorithm) themselves are information that in the digital environment can only be represented in the form of data.
Reproducing data in the form of a bit string is inconvenient for human perception. Therefore, data is usually reproduced in a different, easier-to-read form. This type is determined by the data type that is prescribed for a particular data element: letter, number, text, image, audio recording, etc.
Note - Reproduction is one method of data interpretation. Typically this part of the interpretation is left to the computer.
Example - It may be specified that some data element (in the form of zeros and ones) should be interpreted as a date. The interpretation of this data element by a computer may mean that a program has been entered into the computer to transform the data so that it can be displayed on a screen in a form that can be understood by a human. Otherwise, a program can be entered into the computer that checks the value of a data element and, under certain conditions (equal to a specified value or exceeding set value) transfers control to another program.
The type of a composite data element is an ordered sequence of the types of its subelements.
Text is a familiar representation of information in an analog environment for humans. The interpretation of this representation is based on the knowledge of the reader: in order to read a text, one must, at a minimum, know the language in which it is written. To understand a text, you need to have knowledge in the subject area to which it relates.
Text in the usual human understanding is of little use for automated processing computer programs. In order to computer program could interpret and process the text accordingly, it must contain special signs, invisible to humans during “normal” reproduction, which are called markings(term).
Data types defined in different standards(digit, letter, sign, number, image, audio data, video data, audio-visual data) are a prescription for interpreting the same basic representation of data in a digital environment - the bit string. The data format specifies the method for interpreting the bit string, specifying details such as the sizes of individual fields, methods of visualization (in the general case, reproduction) of data, etc.
The definition of an attribute of an electronic or digital media object should, as a rule, contain the name of the attribute, its format (or, at a minimum, its type).
Service attributes are not necessarily ELD data elements. For example, the attributes “file name”, “date of file creation”, “file size”, etc., characterizing a specific implementation of the electronic document, do not necessarily have to be present in the document data.
The difference between reference and service attributes is fundamental: reference attributes describe a document as an object of the social environment, service attributes describe the implementation of a document as a material object or process in a specific environment of existence. For example, the attribute “document creation date” refers to a document, characterizes the moment the document appeared, regardless of the form in which the document was originally created and currently exists, and should be understood in this sense, regardless of the technical implementation. On the other hand, the "filename" attribute is purely technical, its interpretation is implementation dependent (for example, different operating systems may handle "filename" differently) and is therefore a service attribute. As a consequence, “file name,” like any other service attribute, cannot be a document attribute, but “document creation date” can.
GOST 34.601-90
Group P87
INTERSTATE STANDARD
INFORMATION TECHNOLOGY
Set of standards for automated systems
AUTOMATED SYSTEMS
STAGES OF CREATION
Information technology. Set of standards for automated systems. Automated systems. Stages of development
MKS 35.080
OKSTU 0034
Date of introduction 1992-01-01
INFORMATION DATA
1. DEVELOPED AND INTRODUCED by the USSR State Committee for Product Quality Management and Standards
2. APPROVED AND ENTERED INTO EFFECT by Resolution of the USSR State Committee for Product Quality Management and Standards dated December 29, 1990 N 3469
3. INSTEAD GOST 24.601-86, GOST 24.602-86
4. REFERENCE REGULATIVE AND TECHNICAL DOCUMENTS
Item number, application |
|
GOST 19.101-77 | Annex 1 |
GOST 34.201-89 | Annex 1 |
6*. REISSUE. July 2009
________________
*Numbering corresponds to the original. - Database manufacturer's note.
This standard applies to automated systems (AS) used in various types activities (research, design, management, etc.), including their combinations, created in organizations, associations and enterprises (hereinafter referred to as organizations).
The standard establishes the stages and stages of creating an AS.
Appendix 1 shows the content of work at each stage.
1. GENERAL PROVISIONS
1. GENERAL PROVISIONS
1.1. The process of creating an AS is a set of works ordered in time, interconnected, combined into stages and phases, the implementation of which is necessary and sufficient to create an AS that meets the specified requirements.
1.2. The stages and phases of creating an AS are distinguished as parts of the creation process for reasons of rational planning and organization of work ending with a given result.
1.3. Work on the development of the AS is carried out according to the stages and steps used to create the AS.
1.4. The composition and rules for performing work at the stages and stages established by this standard are determined in the relevant documentation of organizations involved in the creation of specific types of nuclear power plants.
The list of organizations involved in the creation of nuclear power plants is given in Appendix 2.
2. STAGES AND STAGES OF CREATION OF AS
2.1. The stages and stages of creating an AS are generally shown in the table.
Stages of work |
|
1. 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. Development of the AC concept | 2.1. Studying the object |
2.2. Carrying out the necessary research work |
|
2.3. Development of AC concept options and selection of an AC concept option that meets user requirements |
|
2.4. Drawing up a report on the work performed |
|
3. Terms of reference | 3.1. Development and approval of technical specifications for the creation of nuclear power plants |
4. Draft design | 4.1. Development of preliminary design solutions for the system and its parts |
4.2. Development of documentation for the speaker system and its parts |
|
5. Technical design | 5.1. Development of design solutions for the system and its parts |
5.2. Development of documentation for the speaker system and its parts |
|
5.3. Development and execution of documentation for the supply of products for completing the NPP and (or) technical requirements (technical specifications) for their development |
|
5.4. Development of design tasks in adjacent parts of the automation facility project |
|
6. Working documentation | 6.1. Development of working documentation for the system and its parts |
6.2. Development or adaptation of programs |
|
7. Commissioning | 7.1. Preparing the automation object for putting the plant into operation |
7.2. Personnel training |
|
7.3. The complete set of speakers supplied with products (software and hardware, software and hardware complexes, information products) |
|
7.4. Construction and installation works |
|
7.5. Commissioning works |
|
7.6. Carrying out preliminary tests |
|
7.7. Conducting trial operation |
|
7.8. Carrying out acceptance tests |
|
8. AC support | 8.1. Carrying out work in accordance with warranty obligations |
8.2. Post-warranty service |
2.2. The stages and milestones performed by organizations participating in the creation of nuclear power plants are established in contracts and technical specifications based on this standard.
It is allowed to exclude the “Sketch Design” stage and individual stages of work at all stages, to combine the “Technical Design” and “Working Documentation” stages into one “Technical Detailed Design” stage. Depending on the specifics of the AS being created and the conditions for their creation, it is allowed to perform individual stages of work before the completion of previous stages, perform work stages in parallel in time, or include new stages of work.
APPENDIX 1 (for reference). CONTENT OF WORK
ANNEX 1
Information
1. At stage 1.1 “Inspection of the facility and justification of the need to create an NPP”, in the general case, the following is carried out:
- collection of data about the automation object and the types of activities carried out;
- assessing the quality of the functioning of the facility and the types of activities carried out, identifying problems that can be solved by means of automation;
- assessment (technical, economic, social, etc.) of the feasibility of creating an NPP.
2. At stage 1.2 “Formation of user requirements for speakers” the following is carried out:
- preparation of initial data for the formation of requirements for the automated system (characteristics of the automation object, description of the requirements for the system, limitations on acceptable costs for development, commissioning and operation, the effect expected from the system, conditions for the creation and operation of the system);
- formulation and execution of user requirements for speakers.
3. At stage 1.3 “Completing a report on the work performed and an application for the development of an AS (tactical and technical specifications)”, a report on the work performed at this stage and an application for the development of an AS (tactical and technical specifications) or another document replacing it are completed with similar content.
4. At stages 2.1 “Study of the object” and 2.2 “Carrying out the necessary research work,” the development organization conducts a detailed study of the automation object and the necessary research work (R&D) related to finding ways and assessing the possibility of implementing user requirements, draws up and approve research reports.
5. At stage 2.3 “Development of options for the AS concept and selection of an option for the AS concept that meets the user’s requirements”, in the general case, the development alternative options concepts of the AS being created and plans for their implementation; assessment necessary resources for their implementation and operation; assessing the advantages and disadvantages of each option; comparison of user requirements and characteristics of the proposed system and selection of the optimal option; determining the procedure for assessing the quality and conditions for accepting the system; assessment of the effects obtained from the system.
6. At stage 2.4 “Preparing a report on the work performed”, prepare and draw up a report containing a description of the work performed at the stage, a description and justification of the proposed version of the system concept.
7. At stage 3.1 “Development and approval of technical specifications for the creation of a nuclear power plant,” the development, execution, coordination and approval of technical specifications for the nuclear power plant and, if necessary, technical specifications for parts of the nuclear power plant are carried out.
8. At stage 4.1 “Development of preliminary design solutions for the system and its parts” the following are determined: the functions of the AS; functions of subsystems, their goals and effects; composition of task complexes and individual tasks; concepts information base, its enlarged structure; database management system functions; compound computing system; functions and parameters of basic software.
9. At stage 5.1 “Development of design solutions for the system and its parts”, they ensure the development of general solutions for the system and its parts, the functional-algorithmic structure of the system, the functions of personnel and organizational structure, the structure of technical means, algorithms for solving problems and the languages used , on organizing and maintaining an information base, a system of classification and coding of information, on software.
10. At stages 4.2 and 5.2 “Development of documentation for the NPP and its parts”, the development, execution, coordination and approval of documentation is carried out to the extent necessary to describe the full set of design decisions taken and sufficient for the further implementation of work on the creation of the NPP. Types of documents - according to GOST 34.201.
11. At stage 5.3 “Development and execution of documentation for the supply of products for completing NPPs and (or) technical requirements (technical specifications) for their development” the following is carried out: preparation and execution of documentation for the supply of products for completing NPPs; determination of technical requirements and drawing up technical specifications for the development of products that are not mass-produced.
12. At stage 5.4 “Development of design assignments in adjacent parts of the automation facility project,” the development, execution, coordination and approval of design assignments in adjacent parts of the automation facility project are carried out for carrying out construction, electrical, sanitary and other preparatory work related to creation of AS.
13. At stage 6.1 “Development of working documentation for the system and its parts,” working documentation is developed containing all the necessary and sufficient information to ensure the implementation of work on putting the NPP into operation and its operation, as well as to maintain the level of operational characteristics (quality) of the system in accordance with the adopted design decisions, its execution, coordination and approval. Types of documents - according to GOST 34.201.
14. At stage 6.2 “Development or adaptation of programs”, the development of programs and software tools of the system, selection, adaptation and (or) linking of purchased software tools, development program documentation in accordance with GOST 19.101.
15. At stage 7.1 “Preparation of the automation object for putting the plant into operation”, work is carried out on the organizational preparation of the automation object for putting the plant into operation, including: implementation of design solutions for the organizational structure of the plant; providing departments of the management facility with instructional and methodological materials; implementation of information classifiers.
16. At stage 7.2 “Personnel training”, personnel are trained and their ability to ensure the functioning of the plant is checked.
17. At the stage “Completing the speakers with supplied products”, they ensure the receipt of serial and individual production components, materials and installation products. Incoming quality control is carried out.
18. At stage 7.4 “Construction and installation work” the following is carried out: work on the construction of specialized buildings (premises) to accommodate technical equipment and NPP personnel; construction cable channels; performing work on the installation of technical equipment and communication lines; testing of installed technical equipment; delivery of technical equipment for commissioning.
19. At stage 7.5 “Commissioning”, they carry out autonomous adjustment of hardware and software, loading information into the database and checking the system for maintaining it; comprehensive setup of all system tools.
20. At stage 7.6 “Conducting preliminary tests” the following is carried out:
- tests of the AS for operability and compliance with technical specifications in accordance with the program and methodology of preliminary tests;
- troubleshooting and making changes to the NPP documentation, including operational documentation in accordance with the test report;
- drawing up a certificate of acceptance of the NPP for trial operation.
21. At stage 7.7 “Conducting trial operation” the following is carried out: trial operation of the NPP; analysis of the results of trial operation of the NPP; modification (if necessary) of the AS software; additional adjustment (if necessary) of NPP technical equipment; execution of a certificate of completion of trial operation.
22. At stage 7.8 “Conducting acceptance tests” the following is carried out:
Tests for compliance with technical specifications in accordance with the acceptance testing program and methodology;
- analysis of the NPP test results and elimination of deficiencies identified during testing;
- execution of an act of acceptance of the NPP for permanent operation.
23. At stage 8.1 “Performing work in accordance with warranty obligations”, work is carried out to eliminate deficiencies identified during the operation of the NPP during the established warranty periods, and to make the necessary changes to the documentation for the NPP.
24. At stage 8.2 “Post-warranty service” work is carried out on:
- analysis of the functioning of the system;
- identifying deviations of the actual operational characteristics of the NPP from the design values;
- establishing the causes of these deviations;
- eliminating identified deficiencies and ensuring stability of NPP operational characteristics;
- making the necessary changes to the documentation for the speakers.
APPENDIX 2 (for reference). LIST OF ORGANIZATIONS PARTICIPATING IN THE CREATION OF AU
APPENDIX 2
Information
1. The customer organization (user) for which the NPP is being created and which provides financing, acceptance of work and operation of the NPP, as well as execution individual works on the creation of AS;
2. A development organization that carries out work on the creation of the AS, providing the customer with a set of scientific and technical services at different stages and stages of creation, as well as developing and supplying various software and hardware for the AS;
3. A supplier organization that manufactures and supplies software and hardware to the order of the developer or customer;
4. Organization-general designer of the automation facility;
5. Organizations-designers of various parts of the automation facility project for carrying out construction, electrical, sanitary and other preparatory work related to the creation of the nuclear power plant;
6. Construction, installation, commissioning and other organizations.
Notes:
1. Depending on the conditions for creating the NPP, various combinations of functions of the customer, developer, supplier and other organizations involved in the creation of the NPP are possible.
2. The stages and phases of the work they perform to create the AS are determined on the basis of this standard.
Electronic document text
prepared by Kodeks JSC and verified against:
official publication
M.: Standartinform, 2009
The thirty-fourth GOST in the jargon of IT specialists is a set of interrelated standards that have a number starting with 34: GOST 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, as well as the guidance document RD 50-34.698-90 and two stand-alone standards related to the highly specialized topic of cryptographic protection - GOST 34.10 -01 and GOST 34.11-94.
All of these standards appeared in the late 80s - early 90s (the year of issue is indicated by the number after the hyphen), replacing or supplementing the earlier standards of the 19th and 24th series.
To understand and evaluate the logic contained in the GOST 34 family, let us analyze the content of its constituent standards in more detail. GOST 34.320-96 "Concepts and terminology for a conceptual diagram and information base", GOST 34.321-96, aimed at IT specialists. "Reference model for data management", GOST 34.10 -01 "Cryptographic data protection. Processes for generating and verifying electronic digital signature" and GOST 34.11-94 "Cryptographic data protection. I will not consider the hashing function, since they are not intended for managers, but for technical specialists. The following standards are of interest to us:
- GOST 34.201-89. “Types, completeness and designation of documents when creating automated systems”;
- GOST 34.003-90 "Terms and definitions";
- GOST 34.602-89 "Technical specifications for the creation automated system";
- GOST 34.603-92 "Types of testing of automated systems";
- GOST 34.601-90 "Automated systems. Stages of creation";
- Guiding document RD 50-34.698-90 "Automated systems. Requirements for the content of documents."
GOST 34.003-90, in addition to containing numerous errors, is completely outdated and has lost its relevance, so I will not talk about it. Thus, what follows is considered four latest document.
Standard GOST 34.201-89
Seriously outdated, but partly usable standard (GOST 34, 1989a). Establishes compliance of documents with the stages of creation of AS 1 AS is an automated system, i.e. an information system developed or implemented at a specific enterprise., described in GOST 24.601 (later replaced by GOST 34.601). Based on the composition of the documents and the stages of the project, one can trace the origin of the standard from construction practice. Obviously, the project nature of construction and activities to create an information system led the authors of the standard to the idea of extending the basic forms of organizing construction projects to projects for creating information systems. Partly this turned out to be convenient - such documents mentioned in the standard as " Technical task", " Preliminary design ", " Technical project", "Instructions" (for the user), "Program and testing methods" have become firmly established in the practice of creating systems. On the other hand, "List of computer storage media", "Database directory" or "List of original holders" are unlikely to make sense now. The standard also includes elements of office work practice in the form of document coding rules.
In short, with a “creative” approach, it can still serve, especially in those organizations where project activities is regulated by similar project-oriented standards, and the composition of design documents is close to what GOST 34.201-89 offers.
Standard GOST 34.601-90
One of the most widely used standards so far (GOST 34, 1990), which defines the stages and stages of creating an automated system. The table below is central to the standard.
| Stages | Stages |
|---|---|
| 1. 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. Development of the AC concept | 2.1. Studying the object |
| 2.2. Carrying out the necessary research work | |
| 2.3. Development of variants of the speaker concept that meets user requirements | |
| 2.4. Drawing up a report on the work performed | |
| 3. Terms of reference | 3.1 Development and approval of technical specifications for the creation of the NPP |
| 4. Draft design | 4.1. Development of preliminary design solutions for the system and its parts |
| 4.2. Development of documentation for the speaker system and its parts | |
| 5. Technical project | 5.1. Development of design solutions for the system and its parts |
| 5.2. Development of documentation for the speaker system and its parts | |
| 5.3. Development and execution of documentation for the supply of products for completing the NPP and (or) technical requirements (technical specifications) for their development | |
| 5.4. Development of design tasks in adjacent parts of the automation facility project | |
| 6. Working documentation | 6.1. Development working documentation on the system and its parts |
| 6.2. Development or adaptation of programs | |
| 7. Commissioning | 7.1. Preparing the automation object 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. Carrying out preliminary tests | |
| 7.7. Carrying out trial operation | |
| 7.8. Carrying out acceptance tests | |
| 8. AC support | 8.1. Carrying out work in accordance with warranty obligations |
| 8.2. Post-warranty service |
Almost all of the listed stages are still encountered in the practice of creating information systems for enterprises and organizations. Of course, one can criticize the standard for its inflexibility in terms of the sequence and names of stages and stages, but the fact remains that it has demonstrated exceptional vitality, and understanding the reason for this is much more important than criticizing the development of almost 20 years ago. It seems to me that the standard demonstrates that it closely matches its objectives. Firstly, it does not require IT knowledge and is therefore understandable to ordinary managers. Secondly, it is compact and simple in structure, which allows a person unfamiliar with it to quickly get up to speed. Thirdly, it is self-sufficient - there are practically no references to related documents in it (with the exception of GOST 34.201). And finally, it is practical - it is immediately clear how to use it and how to control its use.
In addition to the above table, GOST 34.601-90 contains reference Appendix 1 with a step-by-step breakdown of the work, including an indication of the documents arising as a result of this work, as well as Appendix 2 - “List of organizations participating in the creation of nuclear power plants.” This suggests a way to adapt the standard to specific conditions: it is enough to rework the Applications, and you will get a completely reasonable corporate standard for creating IP. And again, this work is within the power of an ordinary manager.
Standard GOST 34.602-89
The requirement to "prepare Technical task in accordance with GOST 34.602-89", is probably familiar to everyone who has at least once participated in the custom development of an IP or its acceptance, and indeed to everyone who is in one way or another connected with information systems. Some developers still consider it good form to remember by heart the composition of the Technical Specifications (TOR) in accordance with GOST 34.602-89 (GOST 34, 1989b).
- General information.
- Purpose and goals of creation (development) of the system.
- Characteristics of automation objects.
- System requirements.
- Composition and content of work to create the system.
- Procedure for control and acceptance of the system.
- Requirements for the composition and content of work to prepare the automation object for putting the system into operation.
- Documentation requirements.
- Development sources.
Let's try to understand the reasons for the continued popularity of this standard, which has already exceeded 20 years of age. Actually, the entire standard is a transcript of the listed nine points. Its size is only 11 pages, but the volume of information useful information surprisingly big. If we throw out obvious archaisms, such as the funds of algorithms and programs that once existed, it turns out that almost everything about we're talking about, is still fully applicable. Here is an example of one of the sections.
"2.6.2. In the subsection "Requirements for functions (tasks)" performed by the system, the following is given:
- for each subsystem, a list of functions, tasks or their complexes (including those ensuring the interaction of parts of the system) to be automated;
when creating a system in two or more queues - list functional subsystems, individual functions or tasks put into effect in the 1st and subsequent stages;
- time regulations for the implementation of each function, task (or set of tasks);
- requirements for the quality of implementation of each function (task or set of tasks), for the form of presentation output information, characteristics of the required accuracy and execution time, requirements for simultaneous execution of a group of functions, reliability of results;
- list and failure criteria for each function for which reliability requirements are specified."
The above excerpt demonstrates the hierarchical nature of the standard: the system consists of subsystems, complexes of tasks, individual tasks, and functions. The more precise and detailed the requirements are formulated, the more predictable the result will be. Requirements for the functions of interaction of subsystems are specially formulated (now we would say “integration methods”), the functions are tied to the system implementation plan (which thereby also becomes hierarchical). Quality requirements are specifically mentioned. Presentation form output information, i.e. the set of reports also deserves special mention. In a word, the presented excerpt shows that the development of Technical Specifications in accordance with GOST 34.602-89 is not an easy and very labor-intensive job that imposes serious obligations not only on the developer, but also on the customer of the system. The potential of the standard is extremely high, and it is not surprising that its popularity has remained consistently high for so many years.
Over time, the downsides of the standard became visible:
- the standard is focused on completely custom development of a system “from scratch” and is not intended for implementation ready-made solution using a standard methodology or a combination of custom developments and implementations;
- the standard offers one and only model life cycle a system called cascade, when all the work to create the system is linearly ordered and this order is predetermined;
- the standard is too formal. In practice, this leads to the appearance of Technical Specifications, in form meeting the requirements of GOST 34.602-89, but essentially lacking in content.
It is worth emphasizing that, like GOST 34.601-90, GOST 34.602-89 does not require special training in area information technologies, therefore, an ordinary manager, whose task includes, for example, interaction with subcontractors, can monitor compliance with the Technical Specifications. This simplifies implementation and practical use standard
Another interesting phenomenon that practice has demonstrated is that, as it turns out, not every IT specialist is able to develop Technical task, meeting the requirements of the standard. In fact, the appearance of GOST 34.602-89 stimulated the emergence of new specialists - business analysts and consultants in the field of information technology, whose main work was the development and coordination of Technical Specifications with customers of automated systems.
Standards for automated control systems that are not combined into series.
GOST 15971-90. Information processing systems. Terms and Definitions.
GOST 19781-90. Software for information processing systems. Terms and Definitions.
GOST 28806-90. Quality of software. Terms and Definitions. Introduced on January 1, 1992.
GOST 28195-89. Assessing the quality of software. General provisions.
GOST 25868-91. Peripheral equipment for information processing systems. Terms and Definitions. M. Standards Publishing House. 1992, 34 p. Introduced on January 1, 1993.
GOST 28147-89. Information processing systems. Cryptographic protection. Cryptographic conversion algorithms.
GOST 28803-90 (ISO 6523-84). Data exchange. Organization identification structure. Introduced from 01/01/93.
GOST R ISO/IEC 9125-93. Information technology. Evaluation of software products. Quality characteristics and guidelines for their use.
GOST R ISO/IEC TO 9294-93. Information technology. Software Documentation Management Guide.
GOST R ISO 9127-94. Information processing systems. User documentation and packaging information for consumer software packages.
RISO 9126-93. Information processing systems. User documentation and packaging information for consumer software packages.
GOST RISO/IEC 12207. Software life cycle processes. Introduced from 07/01/2000.
GOST R50739-95. Computer facilities. Protection against unauthorized access to information. General technical requirements.
GOST R51188-98. Data protection. Testing software for computer viruses. Model manual.
GOST 28140-89. Information processing systems. Pascal programming language.
GOST R 51169-98. Quality of service information. Information technology certification system in the field of service information quality. Terms and Definitions.
GOST R 51168-98. Quality of service information. Legend elements of technological processes of data processing.
GOST R 51170-98. Quality of service information. Terms and Definitions.
GOST R 51171-98. Quality of service information. Rules for submitting information technologies for certification.
GOST series 34. "Information technology (IT)".
RD 50-680-88. Automated systems. Basic provisions.
RD 50-682-89. Information technology. A set of standards and guidelines for automated systems. General provisions.
GOST 34.003-90. IT. Automated systems. Terms and Definitions.
GOST 34.201-89. IT. Set of standards for automated systems. Types, completeness and designation of documents when creating automated systems.
GOST 34.601-90. IT. Set of standards for automated systems. Automated systems. Stages of creation. (Instead of GOST 24.601-86, 24.602-86).
GOST 34.602-89. IT. Set of standards for automated systems. Terms of reference for the creation of an automated system.
GOST 34.603-89. IT. Types of testing of automated systems.
RD 50-34.698-90. IT. Automated systems. Requirements for the content of documents.
GOST 34.1501.1-92 (ISO/TR 10314-1-90). IT. Industrial automation. Primary production. Part 1. Standardization reference model and methodology for identifying standardization requirements.
GOST series 19. "Unified System of Program Documentation (USPD)".
GOST 19.001-77. Unified system of program documentation. General provisions.
GOST 19.701-90. (ISO 5807-85). ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules. (Instead of GOST 19.002-80, 19.003-80).
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. Stages of development.
GOST 19.103-77. ESPD. Designations of programs and program documents.
GOST 19.104-78. ESPD. Basic inscriptions.
GOST 19.105-78. ESPD. General requirements for program documents.
GOST 19.106-78. ESPD. Requirements for printed program documents.
GOST 19.201-78. ESPD. Technical task. Requirements for creation and design.
GOST 19.202-78. ESPD. Specification. Requirements for content and design.
GOST 19.301-78 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. Program description.
GOST 19.403-79. ESPD. List of holders of originals.
GOST 19.404-79. ESPD. Explanatory note. Requirements for content and design.
GOST 19.501-78. ESPD. Form. Requirements for description and design.
GOST 19.502-78. ESPD. Description of application. Requirements for description and design.
GOST 19.503-79. ESPD. System Programmer's Guide. Requirements for description and design.
GOST 19.504-79. ESPD. Programmer's Guide. Requirements for description and design.
GOST 19.505-79. ESPD. Operator's manual. Requirements for description and design.
GOST 19.506-79. ESPD. Description of the language. Requirements for description 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 documents.
GOST 19.603-78. ESPD. General rules for making changes.
GOST 19.604-78. ESPD. Rules for making changes to printed documents.
GOST series 24. "Unified system of standards for automated control systems (ESSASU)".
GOST 24.104-85. ESSASU. Automated control systems. General requirements.
GOST 24.301-80. System of technical documentation for automated control systems. General requirements for the execution of text documents.
GOST 24.302-80. System of technical documentation for automated control systems. General requirements for the implementation of schemes.
GOST 24.701-86. ESSASU. Reliability of automated control systems. Basic provisions.
GOST 24.702-85. Efficiency of automated control systems. Basic provisions.
GOST 24.703-85. Typical design solutions in automated control systems. Basic provisions.
Instead of GOST 24.601-86 and 24.602-86, see GOST 34.601-90.
Standards in the field of information security.
GOST R 50922-96. Data protection. Basic terms and definitions.
GOST R 50934-96. Data protection. Organization and content of work to protect information about military equipment from technical intelligence. General provisions.
GOST R 50739-95. Computer facilities. Protection against unauthorized access to information. General technical requirements.
GOST R 51188-98. Data protection. Testing software for computer viruses. Model manual.
GOST R 51275-99. Data protection. Information object. Factors influencing information. General provisions.
GOST R 51241-98. Access control tools and systems. Classification. General technical requirements. Test methods.
GOST R 51583-2000. Data protection. The procedure for creating automated systems in a secure design. General requirements.
ISO/IEC 15408-99. Information technology security criteria.
Classification and coding of information.
Materials on standardization.
Standardization rules. Basic provisions and procedure for carrying out work on the development, maintenance and application of all-Russian classifiers. PR 50.1.024-2005. Federal Agency for Technical Regulation and Metrology. Order No. 311-st dated December 14, 2005.
Today we will talk about domestic standards for design documentation. How these standards work in practice, why they are bad and why they are good. When developing documentation for government and serious private customers, we usually have no choice - compliance with standards is included in the requirements for documenting technical specifications. In practice, I have encountered various examples of misunderstanding of the structure of standards, what should be in the documents and why these documents are needed. As a result, the pens of technical writers, analysts and specialists sometimes produce such gems that it is unclear in what state of consciousness they were written. But in fact, everything is quite simple. A search on Habr did not return any links to more or less complete material on this topic, so I propose to fill in this annoying gap.
What are documentation standards?
In the 34 series in question, there are only 3 main documentation standards:The most beloved and popular standard for the development of technical specifications. The only thing you should not forget is that it is tightly connected with other standards of the series and if you received a technical specification made according to this standard, it is highly advisable to adhere to other standards, even if there are no direct requirements for this. At least in terms of general ideology (about which below)
This is a basic document that provides a complete list of GOST 34 documentation, recommendations for coding documents, which project stages the documents belong to (the stages are described in GOST 34.601-90), as well as how they can be combined with each other.
In fact, this standard is large table with comments. It can be put into Excel for ease of use.
A voluminous standard that describes the content of project documents with varying degrees of detail. The above-mentioned GOST 34.201-89 is used as an index.
There are many questions and interpretations of its provisions regarding the RD 50-34.698-90 standard, which, due to their vagueness, are often understood differently by the customer and the contractor, or even members of the project team. But, unfortunately, we don’t have anything more specific.
Let us now consider the pros and cons of the standards, traditionally starting with the cons.
Disadvantages of standards
The main disadvantage is obvious to everyone - the standards are old. They contain an outdated idea of the architecture of an automated system. For example:- two-tier applications, consisting of a client program and a DBMS server (no three or more “tier” applications, no Weblogic or JBoss)
- the structure of the database tables, being described, will give an idea of the logical data model (the fact that there could be some kind of Hibernate between the application and the database seemed like a bad excess then)
- the user interface is single-window (is there anything else? What is a “browser”?)
- There are few reports in the system; they are all paper and printed on a dot-matrix printer.
- The program being developed is focused on solving the “information processing problem,” which has a clear input and output and is highly specialized. Information processing is based on an “algorithm”. Sometimes there are several “algorithms”. (Object-oriented programming was then just taking its first steps and was not seriously considered).
- the database administrator understands what information is in the tables and actively participates in editing system directories (is there really one DBMS server for 50 different applications?)
5.8. Drawing of the document form (video frame)
The document must contain an image of the form of the document or video frame in accordance with the requirements of state standards of the unified documentation system R 50-77 and the necessary explanations.
The point of the document is that Soviet enterprises used so-called “Printing Areas”, where there were high-speed matrix printers, the drivers for which were often written by the engineers themselves. Therefore, they had to maintain a register of all the documents that needed to be printed to ensure that the documents looked as they should when printed.
“Video frame” is also a document that was displayed on text display. Displays did not always support the required characters and required quantity characters horizontally and lines vertically (and graphics were not supported at all). Therefore, here, too, it was necessary to additionally coordinate the forms of all screen documents.
Now the words “machineogram”, “video frame”, “ADC” no longer tell us anything. I also didn’t find them in use, although I graduated from a specialized institute in the 90s. It was time emergence of Windows 3.1, VGA displays, three-inch floppy disks and the first domestic Internet sites. But these words are in the standard, and the customer sometimes capriciously demands that we provide him with a complete set of documentation in accordance with GOST 34.201-89. Moreover, such wording in the ToR migrates from one ministry to another and has already become a kind of unspoken template into which the content is hammered in.
So the document with the stupid name “Drawing of the document form (video frame)” in the project should and should not be empty.
What's good in the standard
Any standard is good in that it allows the customer and the contractor to speak the same language and provides a guarantee that, at least, the customer will not have any complaints “in form” to the transmitted results.
And the GOST 34 standards are also good because they were compiled by smart people, tested over the years, and they have a clear goal - to describe on paper as fully as possible the complex abstract essence that any automated control system represents.
When you need to competently set a task for Western contractors who have never heard of our GOST standards, you can also rely on these standards, or rather on their content and semantic component. Because, I repeat, the guarantee of completeness of information is worth a lot. No matter how much we console ourselves high level our professionalism, we may forget to include elementary things in our requirements, while the same GOST 34.602-89 “remembers” everything. If it is not clear to you what the result of the work of Western contractors should look like, look at the documentation requirements and recommended sections. I assure you, it’s better not to think of it! Most likely, there are Western analogues of our standards, in which everything can be more complete, more modern and better. Unfortunately, I am not familiar with them, since there has not yet been a single case where our GOST standards were not enough.
You can laugh at the fact that the standards creators knew nothing about java or .NET, about HD monitors and the Internet, but I would not advise underestimating the scale of the work they did and its value to our professional community.
How to read and understand documentation standards according to GOST series 34
The standard divides all documents along two axes - time and subject area. If you look at Table 2 in GOST 34.201-89, you can clearly see this division (columns “Creation stage” and “Part of the project”
Stages of creating an automated control system
The stages of creation are defined in GOST 34.601-90. Three of them are relevant to documentation:- Draft design (ED)
- Technical design (TP)
- Development of working documentation (DD)
Technical project describes future system from all angles. Documents at the TP stage should, after reading, leave behind complete clarity in the proposed approaches, methods, architectural and technical solutions. At the next phase it will be too late to describe approaches and justify technical solutions, so phase P is the key to successful delivery of work, since all the variety of requirements of the technical specifications must be reflected in the documents of phase P. At phase P, the system may not exist at all.
Working documentation designed for successful deployment, commissioning and continued operation new system. These are documents containing very specific information that describe physically existing entities, in contrast to the P phase, which describes future splendor.
Parts (sections) of project documentation for the creation of an automated control system
The subject area is divided into “Provisions”. At first it seems that such a division is redundant and unnecessary. But when you start working with this toolkit in practice, the ideology embedded in it gradually becomes clear.An automated system, as envisioned by the compilers of GOST, is a combination of hardware, software and communication channels that processes information coming from different sources information in accordance with certain algorithms and produces processing results in the form of documents, data structures or control actions. A primitive model of the simplest machine gun.
In order to fully describe this “machine”, the following sections are made (as in drawing):
Software (MS), answering the questions: what logic is hardwired inside the “black box”? Why were these particular algorithms, these particular formulas, and these particular coefficients chosen?
Mathematical software knows nothing about processors or databases. This is a separate abstract area, the abode of “spherical horses in a vacuum.” But mathematical software can be very closely related to subject area, aka Real life. For example, control algorithms for traffic control systems must be approved by the State Traffic Safety Inspectorate before they are approved by the customer. And then you understand why they are included in a separate book. Because no one in the traffic police is interested in what OS the application server will run on, but what sign and speed limit will pop up on the board in the rain or snow is very interesting. They are responsible for their part and are not going to sign anything else. On the other hand, when they signed, there will be no questions about the technical side of the issue - why they chose those and not other boards or traffic lights. The wisdom of the “ancestors” is precisely manifested in such practical cases.
Information support (IS). Another slice of the system. This time the black box of our system is made transparent and we look at the information circulating in it. Imagine a model of the human circulatory system when all other organs are invisible. Something like this is Information Support. It describes the composition and routes of information flow inside and outside, the logical organization of information in the system, a description of reference books and coding systems (those who made programs for production know how important they are). The main descriptive part falls on the TP stage, but some “rudiments” flow into the RD stage, like the “Database Catalog” document. It is clear that previously it contained exactly what is written in the title. But today try for a challenging one integrated system create such a document when very often the system uses purchased subsystems with their own mysterious information repositories. I'm not even saying that this document is not particularly needed now.
Or here is the “Statement of computer storage media”. It is clear that previously it contained numbers of magnetic drums or reels of film. Now what should I put in there?
In short, at the RD phase the documents Information support represent a rather harmful rudiment, since formally they should exist, but there is nothing special to fill them with.
Software. Everyone's favorite part of project documentation. Yes, if only because it is just one document! And then, everyone understands what needs to be written down there. But I’ll repeat it anyway.
In this document, we must tell you with the help of which software the algorithms described in the ML are executed, processing the information described in the IR. That is, there is no need to duplicate information from other sections here. Here we give the architecture of the system, the rationale for the selected software technologies, their description (all sorts of system things: programming languages, frameworks, operating systems, etc.). Also in this document we describe how information processing tools are organized (message queues, storage facilities, Reserve copy, accessibility solutions, all sorts of application pools, etc.). The standard contains a detailed description of the contents of this document, which any specialist will understand.
Technical support (TO). No less beloved part of the project documentation. The rosy picture is only clouded by the abundance of documents that need to be developed. In total, the standard requires the development of 22 documents, of which 9 are at the TC stage.
The fact is that the standard provides a description of everything technical support, including computer hardware and networks, engineering systems and even the construction part (if required). And this economy is regulated by a huge number of standards and regulations, coordinated in different organizations, and therefore it is more convenient to split everything into parts and coordinate (edit) in parts. At the same time, the standard allows you to combine some documents with each other, which makes sense if the whole bunch is approved by one person.
Do not forget also that a set of quality standards implies recording and storage of technical documents, and our “books” from the customer may be distributed among different archives, depending on the subject of the description. This is another argument in favor of fragmenting documentation.
Organizational support (OO). Having suppressed the desire, normal for a techie, to skip through this section as quickly as possible, on the contrary, I will consider it in more detail. Since, colleagues, recently there have been some bad trends in projects that require clarification in this section.
At the TP stage, the section contains only one document “ Description of the organizational structure", in which we must tell the customer what he should prepare for in terms of changing the organizational structure. Suddenly you need to organize a new department to operate your system, introduce new positions, etc.
At the RD stage, other, more interesting documents appear, which I would like to consider separately.
User guide. Comments are unnecessary, I think.
Methodology (technology) computer-aided design . If necessary, you can include a description of the process of software building, version control, testing, etc. in this document. But this is if the customer in the technical specification wishes to personally assemble the software. If he doesn’t require this (and doesn’t pay for it), then your entire internal kitchen is none of his business, and this document does not need to be done.
Technological instructions. Due to the fashion for formalizing business processes, a cunning customer sometimes tries to stuff operating regulations into this document. So, under no circumstances should you do this.
Description of business processes, role and job descriptions, work regulations - all this is ORD, that is, organizational and administrative documentation. Which is the product of a consulting project, which, as far as I understand, was not purchased from you. And they bought a technical project from you and also technical documentation for it.
The technological instruction is a layer between the operating instructions and the user manual. The RP describes in detail How you need to do certain actions in the system. The technological instruction says that which actions must be performed in certain cases related to the operation of the system. Roughly speaking, a technological instruction is a short digest of the RP for a specific position or role. If the customer does not have roles formed or he wants you to create roles and job requirements yourself, include the most basic roles in the document, for example: operator, senior operator, administrator. The customer’s comments on the topic “but it’s not like that with us” or “we don’t like it” should be accompanied by a list of roles and a description of job responsibilities. Because business processes we we don't put it. We are these business processes automate.
I will write about the described rakes separately, with colorful examples, since this is not the first time that this has been repeated in different sectors of the “national economy.”
Description of the technological process of data processing (including teleprocessing). A pathetic relic of the cave age, when there were specially designated “Computer Operators” who fed punched cards to the machine and packaged a printout of the result in an envelope. This instruction is for them. I can’t tell you exactly what to write in it in the 21st century. Get out yourself. The best thing is to just forget about this document.
System-wide solutions (WSO). The standard provides for 17 documents in the OP section. Firstly, these are almost all documents of the preliminary phase of Schematic Design. Secondly, these are all kinds of estimates, calculations and brief description automated functions. That is, information for people not from the main IT production, but for support staff - managers, estimators, purchasing specialists, economists, etc.
And thirdly, the OR includes a mega-document called “Explanatory Note to technical project", which is intended to be a kind of Executive Summary, but in fact, many designers shove all the useful content of the TP stage into it. Such a radical approach can be justified and even mutually beneficial for both the customer and the contractor, but in certain cases.
Options for using GOST 34
- Full and exact adherence to the standard. Naturally, no one will write such a cloud of documents voluntarily. Therefore, a complete set of documents is prepared only at the urgent request of the customer, which he secured in the technical specifications and also pinned down with an agreement on top. In this case, you need to take everything literally and give the customer physical “books”, on which will be the names of the documents from Table 2 of GOST 34.201-89, with the exception of completely unnecessary ones, the list of which you must discuss and secure in writing. The content of the documents must also, without any imagination, comply with RD 50-34.698-90, right down to the names of the sections. In order for the customer's brain to explode, sometimes big system are divided into subsystems, and separate design documentation is issued for each subsystem. It looks terrifying and is not subject to normal control with the help of the earthly mind. Especially regarding the integration of subsystems. Which greatly simplifies acceptance. The main thing is that you yourself do not get confused and that your system still works as it should.
- We just love GOSTs. Serious big companies love standards. Because they help people understand each other better. If your customer is noted for his love of order and standardization, try to adhere to the standard GOST ideology when developing documents, even if this is not required by the technical specifications. The approving specialists will understand you better and approve of you, and you yourself will not forget to include them in the documentation important information, you will better see the target structure of documents, plan the work of writing them more accurately, and save yourself and your colleagues a lot of nerves and money.
- We don't care about documentation, as long as everything works. The vanishing appearance of the irresponsible customer. A similar view of documentation can still be found among small and poor customers, as well as in authoritarian “idiotocracies” left over from the time of perestroika, where the boss is surrounded by loyal friends - directors, and all issues are resolved in personal conversations. In such conditions, you are free to neglect documentation altogether, but it is better, after all, not to knock down the sight and at least schematically fill in the documentation with content. If not to this customer, then pass it on (sell it) to the next one.
Conclusion
This article was about our GOST standards for documenting automated control systems. GOSTs are old, but, as it turns out, they are still very useful in the household. Apart from some obvious rudiments, the structure of the documentation has the properties of completeness and consistency, and adherence to the standard eliminates many project risks, the existence of which we may not be aware of at first.
I hope the material presented was useful to you, or at least interesting. Despite the apparent tedium, documenting is an important and responsible job, accuracy in which is just as important as when writing good code. Write good documents, Colleagues! And next week I’m going on two business trips in a row, so I can’t guarantee the publication of new materials (I don’t have a cache, I’m writing from my head).
