August 18, 2010 at 16:42About GOSTs on GOS sites
Today in his blog Sergey Nazaruk published excerpts from the standard , according to which the websites of government agencies should be developed. An interesting document.
Immediately, a wave of discussions arose in Habré , where, among other things, there are statements about the revival of the scoop, “don’t stop us from doing our job ... well, and other negative opinions. But the document seems to me very necessary and useful.
Why do we need standards? To think less when making some decisions. At the same time, through the accumulated and collected in the standard of knowledge to improve the quality of these solutions. I will give an example. In the 80s, the US military was puzzled by the procedure for selecting vendors for the development and supply of software. How to choose contractors? It was necessary to introduce some indicators-levels of companies in order to separate those who work reliably from those who work randomly. Ideally, this indicator is only one number: 1,2,3,4,5 ... A company of level 5 is better than a company of level 3, therefore we work with a company of level 5. So the CMMI (Capability Maturity Model Integration) standard appeared . The company of EPAM - 4th level (5-of), then on the market, it looks more attractive than those who have a 2nd or 3rd.
Somehow I had to deal with the development of Internet projects for government agencies. This occupation is not easy and involves a lot of risks. The result often depended only on the quality of the established relations with a particular official. But if it was changed - it was possible to throw the written product into the trash - his deputy again demanded a strange one. The only way out is to clearly fix the requirements and each movement in the project. Even then, I wrote TK in accordance with GOSTs, which delighted officials.
So why do we need such a standard?
Currently, the quality of many Internet projects of government agencies and agencies is lower than the plinth. It is no secret that these sites were developed as they should, the procedures for updating them do not exist, and it is not worth talking about information protection. Sometimes work falls to the poor system administrator.
The document applies to the W3C standards, which should greatly please web standards, as well as to a number of usability standards.
The positive thing is that a number of requirements have already been formed at the standard level. This directly means that when drawing up the Terms of Reference, you can refer to the provisions of this standard. When I was engaged in analytics for Belarusian projects, I really did not have such a standard.
It is no secret that acceptance of work when working for government customers is always a problem. There are two reasons for this:
The fact is that if the non-functional requirements are not clearly spelled out in the TOR, the customer can appeal to industry standards. If we lived in the EU, the appeal would be to ISO standards. And here it would not seem a little.
In general, in short, such a standard removes a number of questions and sets the basis for decision-making by officials. And if the standard is obtained at the output of high enough quality, then it makes sense to refer to it when developing commercial sites.
It’s funny to hear that with the introduction of such a standard, web developers will have to tighten. :) Firstly, you can close up the whole label, what we say is doing according to the standard - go to us! Secondly, to build a harmonious development process under this business - it is easier with the standard.
At the same time, I do not want to say that the document is beautiful, excellent and should be accepted unchanged. I did not read the whole document, only what Sergey laid out. From what I read - a lot of things are very much the case. He has the right to life.
What is wrong:
If normal methodologists get to the document, they will correct these nuances. In general, the direction is positive.
Immediately, a wave of discussions arose in Habré , where, among other things, there are statements about the revival of the scoop, “don’t stop us from doing our job ... well, and other negative opinions. But the document seems to me very necessary and useful.
Why do we need standards? To think less when making some decisions. At the same time, through the accumulated and collected in the standard of knowledge to improve the quality of these solutions. I will give an example. In the 80s, the US military was puzzled by the procedure for selecting vendors for the development and supply of software. How to choose contractors? It was necessary to introduce some indicators-levels of companies in order to separate those who work reliably from those who work randomly. Ideally, this indicator is only one number: 1,2,3,4,5 ... A company of level 5 is better than a company of level 3, therefore we work with a company of level 5. So the CMMI (Capability Maturity Model Integration) standard appeared . The company of EPAM - 4th level (5-of), then on the market, it looks more attractive than those who have a 2nd or 3rd.
Somehow I had to deal with the development of Internet projects for government agencies. This occupation is not easy and involves a lot of risks. The result often depended only on the quality of the established relations with a particular official. But if it was changed - it was possible to throw the written product into the trash - his deputy again demanded a strange one. The only way out is to clearly fix the requirements and each movement in the project. Even then, I wrote TK in accordance with GOSTs, which delighted officials.
So why do we need such a standard?
Quality bar
Currently, the quality of many Internet projects of government agencies and agencies is lower than the plinth. It is no secret that these sites were developed as they should, the procedures for updating them do not exist, and it is not worth talking about information protection. Sometimes work falls to the poor system administrator.
The document applies to the W3C standards, which should greatly please web standards, as well as to a number of usability standards.
Statement of requirements
The positive thing is that a number of requirements have already been formed at the standard level. This directly means that when drawing up the Terms of Reference, you can refer to the provisions of this standard. When I was engaged in analytics for Belarusian projects, I really did not have such a standard.
Acceptance of work
It is no secret that acceptance of work when working for government customers is always a problem. There are two reasons for this:
- Often there are not enough qualified specialists to carry out the acceptance of work. To prove that you are right is very difficult. As a result, very detailed quality requirements have to be written in the TOR.
- Sprawl requirements. Realizing that after acceptance the contract is closed, the customer is trying to push through new and new requirements.
The fact is that if the non-functional requirements are not clearly spelled out in the TOR, the customer can appeal to industry standards. If we lived in the EU, the appeal would be to ISO standards. And here it would not seem a little.
In general, in short, such a standard removes a number of questions and sets the basis for decision-making by officials. And if the standard is obtained at the output of high enough quality, then it makes sense to refer to it when developing commercial sites.
It’s funny to hear that with the introduction of such a standard, web developers will have to tighten. :) Firstly, you can close up the whole label, what we say is doing according to the standard - go to us! Secondly, to build a harmonious development process under this business - it is easier with the standard.
At the same time, I do not want to say that the document is beautiful, excellent and should be accepted unchanged. I did not read the whole document, only what Sergey laid out. From what I read - a lot of things are very much the case. He has the right to life.
What is wrong:
- Use of quality definitions. “Page elements should be easily identifiable” - it’s not clear what it means easily? Such language should be avoided in standards and requirements.
- Fuzzy structure. For example, about security in the Design section. :)
If normal methodologists get to the document, they will correct these nuances. In general, the direction is positive.