Documentation according to GOST 34 * is just
Today we will talk about domestic standards for project documentation. How do these standards work in practice, how are they bad and good? When developing documentation for public and serious private customers, we usually have no choice - compliance with standards is included in the documentation requirements for TK. In practice, I have come across various examples of misunderstanding of the structure of standards, what should be in the documents and why these documents are needed. As a result, sometimes such pearls come out from the pen of technical writers, analysts and specialists, which makes it unclear in what state of consciousness they were written. But in fact, everything is quite simple. Search on Habra did not return links to more or less holistic material on this topic, because I propose to paint this annoying gap.
In the series 34 in question, there are only 3 main standards for documentation:
GOST 34.602-89 Terms of Reference for the creation of an automated system
')
The most beloved and popular standard for the development of TK. The only thing you should not forget is that it is tightly connected with other standards of the series and if you have received the TK performed according to this standard, it is highly desirable to adhere to other standards, even if there are no direct requirements. At least in terms of a general ideology (about which below)
GOST 34.201-89 Types, completeness and designation of documents when creating automated systems
This is a basic document, which contains a complete list of GOST 34 documentation, recommendations for coding documents, which stages of a project documents are (stages are described in GOST 34.601-90), and how they can be combined with each other.
In fact, this standard is a large table with comments. It can be driven into Excel for ease of use.
RD 50-34.698-90 Automated systems. Requirements for the content of documents
A voluminous standard that describes the contents of project documents in various degrees of detail. As an index, the aforementioned GOST 34.201-89 is used.
There are many questions and interpretations of its provisions to the standard RD 50-34.698-90, which, because of their vague, are often understood differently by the customer and the performer or even by the members of the project team. But we have nothing more specific, unfortunately.
We now consider the pros and cons of standards, starting traditionally with minuses.
The main disadvantage is obvious to all - the standards are old. They contain an outdated understanding of the architecture of an automated system. For example:
Accordingly, there are artifacts in the standard, like the following:
The meaning of the document is that the Soviet enterprises used the so-called "Sections of printing", where there were high-speed matrix printers, to which the engineers themselves often wrote drivers. Therefore, they had to maintain a register of all documents that were required to be printed in order to ensure that in printed form the documents would look like they should be.
"Video frame" is also a document that was displayed on a text display. Displays did not always support the required characters and the required number of characters horizontally and lines vertically (and did not support graphics at all). Therefore, here, too, it was necessary to further coordinate the forms of all screen documents.
Now the words “machine image”, “video frame”, “ADCU” do not tell us anything. I also did not find them in use, although I graduated from a specialized institute in the 90s. It was the time of the appearance of Windows 3.1, VGA displays, three-inch floppy disks and the first domestic Internet sites. But in the standard these words are, and the customer sometimes capriciously demands to provide him with a complete set of documentation in accordance with GOST 34.201-89. Moreover, such formulations in TK wander from one ministry to another and have already become some kind of unspoken pattern into which the content part is driven in.
So the document with the stupid title “Drawing the form of the document (video frame)” in the project should be and should not be empty.
Any standard is good because it allows the customer and the contractor to speak the same language and gives a guarantee that, at least, the customer will not have any claims “on the form” to the transmitted results.
And the standards of GOST 34 are also good because they were compiled by intelligent people, tested for years and have a clear goal - to describe as completely as possible on paper the complex abstract entity that any automated control system represents.
When you need to correctly set the task to Western contractors, who have never heard of our GOST standards, you can also rely on these standards, or rather on their content, the semantic component. Because, I repeat, the guarantee of completeness of information is worth a lot. No matter how we would not be amused by the high level of our professionalism, we may forget to include elementary things in our requirements, while the same GOST 34.602-89 “remembers” everything. If you don’t understand how the result of the work of western contractors should look, look at the documentation requirements and recommended sections. I assure you, it is better not to think up! Most likely, there are Western analogues of our standards, in which everything can be fuller, more modern and better. Unfortunately, I am not familiar with them, as there has not been a single case so far that our guests should not be enough.
You can laugh at the fact that the standards makers did not know anything 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 for our professional community.
The standard divides all documents in two axes - time and subject area. If you look at table 2 in GOST 34.201-89, then you can clearly see this division (columns “Stage of creation” and “Part of the project”
The stages of creation are defined in GOST 34.601-90. There are three of them related to documentation:
The draft design follows the technical assignment stage and serves to develop preliminary design solutions.
The technical project describes the future system from all angles. After reading, documents of the TP stage should leave behind themselves complete clarity in the proposed approaches, methods, architectural and technical solutions. At the next phase, it will be too late to describe the approaches and substantiate the technical solutions, so phase P is the key to successful completion of the work, since all the diversity of TOR requirements should be reflected in the documents of phase P. At stage P, the system may not exist at all.
The working documentation is intended for successful deployment, commissioning and further operation of the new system. These are documents containing very specific information describing physically existing entities, in contrast to phase II, where future magnificence is described.
The subject area is divided into "Provisions". At first it seems that such a division is redundant and unnecessary. But when you begin to work in practice with this tool, the ideology invested in it gradually comes.
An automated system in the view of compilers of the GOST is a collection of iron, software and communication channels that processes information from different sources in accordance with certain algorithms and provides the results of processing in the form of documents, data structures or control actions. Primitive model of the simplest automaton.
In order to fully describe this “automaton”, the following cuts were made (as in the drawing):
Mathematical software (MO) , answering the questions: what is the logic sewn inside the “black box”? Why are these algorithms chosen, exactly such formulas and exactly such coefficients?
The software does not know anything about processors or databases. This is a separate abstract area, the abode of "spherical horses in a vacuum." But the software is very tightly connected with the subject area, aka Real life. For example, control algorithms for traffic control systems need to be coordinated with the traffic police before they are agreed by the customer. And then you understand why they are isolated in a separate booklet. Because in traffic police nobody is interested in what OS the application server will work on, but what sign and speed limit will pop up on the scoreboard in rain or snow is very interesting. They are responsible for their part, and they are not going to sign anything else. On the other hand, when they signed, there will be no questions to the technical side of the question - why did they choose, and not other boards or traffic lights. The wisdom of the “ancestors” is precisely manifested in such practical cases.
Information support (IT) . Another cut of the system. This time the black box of our system is made transparent and we are looking at the information circulating in it. Imagine a model of a person’s circulatory system when all other organs are invisible. Here is something similar and there is information support. It describes the composition and routes of information passing inside and outside, the logical organization of information in the system, the description of directories 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 before he contained exactly what is written in the title. But today, try for a complex integrated system to form such a document, when very often the purchased subsystems with their mysterious information repositories are used as part of the system. I'm not talking about the fact that this document is not particularly needed right now.
Or here is the “Statement of Machine Data Media”. It is clear that before it had numbers of magnetic drums or reels with a film. And now what to put there?
In short, during the RD phase, Information Support documents are a rather harmful rudiment, since formally they should be, but there is nothing to fill them with.
Software (software) . Favorite part of all project documentation. Yes, if only because it is just one document! And then, everyone understands that there need to write. But I, nevertheless, will repeat.
In this document we have to tell with what software the algorithms described in MO are executed, processing the information described in IO. That is, there is no need to duplicate information from other sections here. Here is given the system architecture, the rationale for the selected software technologies, their description (all sorts of systemic things: programming languages, frameworks, operating systems, etc.). Also in this document, we describe how information processing tools are organized (message queues, repositories, backup tools, accessibility solutions, all kinds of application pools, etc.). The standard has a detailed description of the content of this document, which will be understood by any specialist.
Technical support (MOT) . No less loved by all part of the project documentation. The rainbow picture is darkened only by the abundance of documents that need to be developed. According to the standard, 22 documents are required to be developed, of which 9 are at the TP stage.
The fact is that the standard provides a description of all 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, is consistent in different organizations and therefore it is more convenient to split everything into pieces and coordinate (edit) in parts. At the same time, the standard allows you to combine some documents with each other, which makes sense to do if the whole bunch is agreed by one person.
Do not forget also that the complex of quality standards implies the accounting and storage of technical documents, and our “booklets” at the customer may differ in different archives, depending on the subject of the description. This is another argument for crushing documentation.
Organizational support (GS) . Having suppressed in itself the desire, normal for a techie, to slip this section as soon as possible, on the contrary, I will consider it in more detail. Since, colleagues, recently there have been some bad trends on the 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 posts, etc.
At the stage of RD there are other, more interesting documents that I would like to consider separately.
User Guide . No comments, I think.
Technique (technology) of computer-aided design . In this document, if necessary, you can put a description of the software assembly process, version control, testing, etc. But this is if the customer wants to assemble the software himself. If he does not require it (and does not pay for it), then your entire internal kitchen is not his business, and this document is not necessary.
Technological instruction . In connection with the fashion for the formalization of business processes, in this document the cunning customer sometimes seeks to cram the regulations of the operation of the operation service. So, do this in any case not necessary.
Description of business processes, role and job descriptions, work regulations - all are OSA, that is, organizational and administrative documentation. Which is a product of a consulting project, which, as I understand it, you did not buy. And they bought a technical project from you and technical documentation for it.
Technological instruction is a layer between the OSA and the user manual. RP describes in detail how to do certain actions in the system. Technological instruction tells what actions need to be performed in those or other cases related to the operation of the system. Roughly speaking, the technology instruction is a short digest of the RP for a particular position or role. If the customer has no roles or he wants you to create roles and job requirements, include the most basic roles in the document, for example: operator, senior operator, administrator. Customer's comments on the topic, “but we don’t have this way” or “but we don’t like it” should be accompanied by a list of roles and job description. Because we do not set up business processes. We automate these business processes.
I will write about the described rakes separately, with colorful examples, since this is repeated not for the first time in various branches of the “national economy”.
Description of data processing (including teleprocessing) . A pitiful rudiment of the cave age, when there were specially allocated “Computer Operators” who fed punch cards to the machine and packed the printout of the result into an envelope. This instruction is for them. What to write in it in the XXI century - I can not say for sure. Get out yourself. The best thing is to just forget about this document.
System-wide solutions (PR) . The standard provides for 17 documents of the PR section. Firstly, it is almost all documents of the preliminary phase of Outline Design. Secondly, it is all sorts of estimates, calculations and brief descriptions of automated functions. That is, information for people not from the mainstream IT production, but for support staff - managers, estimators, procurement specialists, economists, etc.
And thirdly, the PR includes a mega-document entitled “Explanatory Note to the Technical Project”, which is thought to be a kind of Executive Summary, and in fact many designers push into it in general all the useful content of the TA stage. Such a radical approach is justified and even mutually beneficial to the customer and the contractor, but in certain cases.
Variants of using GOST 34
This article was about our guests on documenting ACS. GOSTs are old, but as it turned out, still very useful in the household. Apart from some obvious rudiments, the documentation structure has the properties of completeness and consistency, and following the standard removes many of the design risks, the existence of which we can not guess at first.
I hope, the stated material was useful to you, or, at least, interesting. Despite external boredom, documentation is important and responsible work, accuracy in which is as important as when writing good code. Write good documents, colleagues! And next week I go on two business trips in a row, so I don’t guarantee publication of new materials (I don’t have a zagashnik, I’m writing from my head).
What are standards for documentation?
In the series 34 in question, there are only 3 main standards for documentation:
GOST 34.602-89 Terms of Reference for the creation of an automated system
')
The most beloved and popular standard for the development of TK. The only thing you should not forget is that it is tightly connected with other standards of the series and if you have received the TK performed according to this standard, it is highly desirable to adhere to other standards, even if there are no direct requirements. At least in terms of a general ideology (about which below)
GOST 34.201-89 Types, completeness and designation of documents when creating automated systems
This is a basic document, which contains a complete list of GOST 34 documentation, recommendations for coding documents, which stages of a project documents are (stages are described in GOST 34.601-90), and how they can be combined with each other.
In fact, this standard is a large table with comments. It can be driven into Excel for ease of use.
RD 50-34.698-90 Automated systems. Requirements for the content of documents
A voluminous standard that describes the contents of project documents in various degrees of detail. As an index, the aforementioned GOST 34.201-89 is used.
There are many questions and interpretations of its provisions to the standard RD 50-34.698-90, which, because of their vague, are often understood differently by the customer and the performer or even by the members of the project team. But we have nothing more specific, unfortunately.
We now consider the pros and cons of standards, starting traditionally with minuses.
Cons of standards
The main disadvantage is obvious to all - the standards are old. They contain an outdated understanding of the architecture of an automated system. For example:
- two-level applications consisting of a client program and a DBMS server (no three or more "leveled" applications, no Weblogic or JBoss)
- The structure of the database tables, when 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, then it seemed to be a bad overkill)
- the user interface is one-windowed (is there another? And what is a “browser”?)
- There are few reports in the system, they are all paper and printed on a matrix printer.
- The developed program is focused on solving the “information processing task”, which has a clear entry and exit and is highly specialized. The basis of information processing is the "algorithm". Sometimes there are several “algorithms”. (Object-oriented programming then took only its first steps and was not seriously considered).
- the database administrator understands what information is in the tables and is actively involved in editing system directories (does one have a DBMS server for 50 different applications?)
Accordingly, there are artifacts in the standard, like the following:
5.8. ()
50-77 .
The meaning of the document is that the Soviet enterprises used the so-called "Sections of printing", where there were high-speed matrix printers, to which the engineers themselves often wrote drivers. Therefore, they had to maintain a register of all documents that were required to be printed in order to ensure that in printed form the documents would look like they should be.
"Video frame" is also a document that was displayed on a text display. Displays did not always support the required characters and the required number of characters horizontally and lines vertically (and did not support graphics at all). Therefore, here, too, it was necessary to further coordinate the forms of all screen documents.
Now the words “machine image”, “video frame”, “ADCU” do not tell us anything. I also did not find them in use, although I graduated from a specialized institute in the 90s. It was the time of the appearance of Windows 3.1, VGA displays, three-inch floppy disks and the first domestic Internet sites. But in the standard these words are, and the customer sometimes capriciously demands to provide him with a complete set of documentation in accordance with GOST 34.201-89. Moreover, such formulations in TK wander from one ministry to another and have already become some kind of unspoken pattern into which the content part is driven in.
So the document with the stupid title “Drawing the form of the document (video frame)” in the project should be and should not be empty.
What is good in standard
Any standard is good because it allows the customer and the contractor to speak the same language and gives a guarantee that, at least, the customer will not have any claims “on the form” to the transmitted results.
And the standards of GOST 34 are also good because they were compiled by intelligent people, tested for years and have a clear goal - to describe as completely as possible on paper the complex abstract entity that any automated control system represents.
When you need to correctly set the task to Western contractors, who have never heard of our GOST standards, you can also rely on these standards, or rather on their content, the semantic component. Because, I repeat, the guarantee of completeness of information is worth a lot. No matter how we would not be amused by the high level of our professionalism, we may forget to include elementary things in our requirements, while the same GOST 34.602-89 “remembers” everything. If you don’t understand how the result of the work of western contractors should look, look at the documentation requirements and recommended sections. I assure you, it is better not to think up! Most likely, there are Western analogues of our standards, in which everything can be fuller, more modern and better. Unfortunately, I am not familiar with them, as there has not been a single case so far that our guests should not be enough.
You can laugh at the fact that the standards makers did not know anything 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 for our professional community.
How to read and understand documentation standards in accordance with GOST series 34
The standard divides all documents in two axes - time and subject area. If you look at table 2 in GOST 34.201-89, then you can clearly see this division (columns “Stage of creation” and “Part of the project”
Stages of creation of the ACS
The stages of creation are defined in GOST 34.601-90. There are three of them related to documentation:
- Draft design (EP)
- Technical project (TP)
- Development of working documentation (PD)
The draft design follows the technical assignment stage and serves to develop preliminary design solutions.
The technical project describes the future system from all angles. After reading, documents of the TP stage should leave behind themselves complete clarity in the proposed approaches, methods, architectural and technical solutions. At the next phase, it will be too late to describe the approaches and substantiate the technical solutions, so phase P is the key to successful completion of the work, since all the diversity of TOR requirements should be reflected in the documents of phase P. At stage P, the system may not exist at all.
The working documentation is intended for successful deployment, commissioning and further operation of the new system. These are documents containing very specific information describing physically existing entities, in contrast to phase II, where future magnificence is described.
Parts (sections) of project documentation for the creation of automated control systems
The subject area is divided into "Provisions". At first it seems that such a division is redundant and unnecessary. But when you begin to work in practice with this tool, the ideology invested in it gradually comes.
An automated system in the view of compilers of the GOST is a collection of iron, software and communication channels that processes information from different sources in accordance with certain algorithms and provides the results of processing in the form of documents, data structures or control actions. Primitive model of the simplest automaton.
In order to fully describe this “automaton”, the following cuts were made (as in the drawing):
Mathematical software (MO) , answering the questions: what is the logic sewn inside the “black box”? Why are these algorithms chosen, exactly such formulas and exactly such coefficients?
The software does not know anything about processors or databases. This is a separate abstract area, the abode of "spherical horses in a vacuum." But the software is very tightly connected with the subject area, aka Real life. For example, control algorithms for traffic control systems need to be coordinated with the traffic police before they are agreed by the customer. And then you understand why they are isolated in a separate booklet. Because in traffic police nobody is interested in what OS the application server will work on, but what sign and speed limit will pop up on the scoreboard in rain or snow is very interesting. They are responsible for their part, and they are not going to sign anything else. On the other hand, when they signed, there will be no questions to the technical side of the question - why did they choose, and not other boards or traffic lights. The wisdom of the “ancestors” is precisely manifested in such practical cases.
Information support (IT) . Another cut of the system. This time the black box of our system is made transparent and we are looking at the information circulating in it. Imagine a model of a person’s circulatory system when all other organs are invisible. Here is something similar and there is information support. It describes the composition and routes of information passing inside and outside, the logical organization of information in the system, the description of directories 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 before he contained exactly what is written in the title. But today, try for a complex integrated system to form such a document, when very often the purchased subsystems with their mysterious information repositories are used as part of the system. I'm not talking about the fact that this document is not particularly needed right now.
Or here is the “Statement of Machine Data Media”. It is clear that before it had numbers of magnetic drums or reels with a film. And now what to put there?
In short, during the RD phase, Information Support documents are a rather harmful rudiment, since formally they should be, but there is nothing to fill them with.
Software (software) . Favorite part of all project documentation. Yes, if only because it is just one document! And then, everyone understands that there need to write. But I, nevertheless, will repeat.
In this document we have to tell with what software the algorithms described in MO are executed, processing the information described in IO. That is, there is no need to duplicate information from other sections here. Here is given the system architecture, the rationale for the selected software technologies, their description (all sorts of systemic things: programming languages, frameworks, operating systems, etc.). Also in this document, we describe how information processing tools are organized (message queues, repositories, backup tools, accessibility solutions, all kinds of application pools, etc.). The standard has a detailed description of the content of this document, which will be understood by any specialist.
Technical support (MOT) . No less loved by all part of the project documentation. The rainbow picture is darkened only by the abundance of documents that need to be developed. According to the standard, 22 documents are required to be developed, of which 9 are at the TP stage.
The fact is that the standard provides a description of all 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, is consistent in different organizations and therefore it is more convenient to split everything into pieces and coordinate (edit) in parts. At the same time, the standard allows you to combine some documents with each other, which makes sense to do if the whole bunch is agreed by one person.
Do not forget also that the complex of quality standards implies the accounting and storage of technical documents, and our “booklets” at the customer may differ in different archives, depending on the subject of the description. This is another argument for crushing documentation.
Organizational support (GS) . Having suppressed in itself the desire, normal for a techie, to slip this section as soon as possible, on the contrary, I will consider it in more detail. Since, colleagues, recently there have been some bad trends on the 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 posts, etc.
At the stage of RD there are other, more interesting documents that I would like to consider separately.
User Guide . No comments, I think.
Technique (technology) of computer-aided design . In this document, if necessary, you can put a description of the software assembly process, version control, testing, etc. But this is if the customer wants to assemble the software himself. If he does not require it (and does not pay for it), then your entire internal kitchen is not his business, and this document is not necessary.
Technological instruction . In connection with the fashion for the formalization of business processes, in this document the cunning customer sometimes seeks to cram the regulations of the operation of the operation service. So, do this in any case not necessary.
Description of business processes, role and job descriptions, work regulations - all are OSA, that is, organizational and administrative documentation. Which is a product of a consulting project, which, as I understand it, you did not buy. And they bought a technical project from you and technical documentation for it.
Technological instruction is a layer between the OSA and the user manual. RP describes in detail how to do certain actions in the system. Technological instruction tells what actions need to be performed in those or other cases related to the operation of the system. Roughly speaking, the technology instruction is a short digest of the RP for a particular position or role. If the customer has no roles or he wants you to create roles and job requirements, include the most basic roles in the document, for example: operator, senior operator, administrator. Customer's comments on the topic, “but we don’t have this way” or “but we don’t like it” should be accompanied by a list of roles and job description. Because we do not set up business processes. We automate these business processes.
I will write about the described rakes separately, with colorful examples, since this is repeated not for the first time in various branches of the “national economy”.
Description of data processing (including teleprocessing) . A pitiful rudiment of the cave age, when there were specially allocated “Computer Operators” who fed punch cards to the machine and packed the printout of the result into an envelope. This instruction is for them. What to write in it in the XXI century - I can not say for sure. Get out yourself. The best thing is to just forget about this document.
System-wide solutions (PR) . The standard provides for 17 documents of the PR section. Firstly, it is almost all documents of the preliminary phase of Outline Design. Secondly, it is all sorts of estimates, calculations and brief descriptions of automated functions. That is, information for people not from the mainstream IT production, but for support staff - managers, estimators, procurement specialists, economists, etc.
And thirdly, the PR includes a mega-document entitled “Explanatory Note to the Technical Project”, which is thought to be a kind of Executive Summary, and in fact many designers push into it in general all the useful content of the TA stage. Such a radical approach is justified and even mutually beneficial to the customer and the contractor, but in certain cases.
Variants of using GOST 34
- Full and exact following to the standard . Naturally, no one will voluntarily write such a cloud of documents. Therefore, a complete set of documents is prepared only at the insistent request of the customer, which he enshrined in the TK and also pressed the contract from above. In this case, you need to understand everything literally and give the customer the physical “books” on which the names of documents from Table 2 of GOST 34.201-89 will stand, with the exception of absolutely unnecessary ones, which you must necessarily discuss and fix in writing. The content of the documents should also be without any imagination comply with RD 50-34.698-90, up to the title of the sections. In order for the customer to explode the brain, sometimes a large system is divided into subsystems, and for each subsystem they release a separate project documentation. It looks frightening and is not subject to normal control with the help of the earthly mind. Especially in the integration of subsystems. Which greatly simplifies the 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 . In serious big companies, they like standards. Because they help people better understand each other. If your customer is seen in the love of order and standardization, try to adhere to the standard ideology of GOST in the development of documents, even if it does not require TK. The coordinating specialists will better understand and approve you, and you yourself will not forget to include important information in the documentation, you will better see the target structure of the documents, plan work on their writing more precisely, and save yourself a lot of nerves and money.
- We don't care about documentation, so long as everything works . Disappearing kind of irresponsible customer. Such a look at the documentation can still be found in small and poor customers, as well as in authoritarian “idiotocracies” remaining from the time of restructuring, where the boss is surrounded by true friends - directors, and all issues are resolved in personal conversations. You are free in such conditions to hammer on documentation in general, but it is better, all the same, not to bring down the sight and at least schematically fill in the contents of the documentation. If not to this customer, pass it on to the next one (sell it).
Conclusion
This article was about our guests on documenting ACS. GOSTs are old, but as it turned out, still very useful in the household. Apart from some obvious rudiments, the documentation structure has the properties of completeness and consistency, and following the standard removes many of the design risks, the existence of which we can not guess at first.
I hope, the stated material was useful to you, or, at least, interesting. Despite external boredom, documentation is important and responsible work, accuracy in which is as important as when writing good code. Write good documents, colleagues! And next week I go on two business trips in a row, so I don’t guarantee publication of new materials (I don’t have a zagashnik, I’m writing from my head).
Source: https://habr.com/ru/post/122700/
All Articles