GOS साइटों पर GOSTs के बारे में

आज अपने ब्लॉग में सर्गेई नज़रुक ने मानक से अंश प्रकाशित किए , जिसके अनुसार सरकारी एजेंसियों की वेबसाइटों को विकसित किया जाना चाहिए। एक दिलचस्प दस्तावेज।



इसके तुरंत बाद, हेबे में चर्चाओं की एक लहर पैदा हुई , जहां, अन्य बातों के अलावा, स्कूप के पुनरुद्धार के बारे में बयान हैं, "हमें अपना काम करने से नहीं रोकना चाहिए ... अच्छी तरह से, और अन्य नकारात्मक राय। मुझे दस्तावेज़ बहुत आवश्यक और उपयोगी लगे।



हमें मानकों की आवश्यकता क्यों है? कुछ निर्णय लेते समय कम सोचने के लिए। साथ ही, इन समाधानों की गुणवत्ता में सुधार करने के लिए, मानक में संचित और एकत्रित ज्ञान के माध्यम से। मैं एक उदाहरण दूंगा। 80 के दशक में, अमेरिकी सेना सॉफ्टवेयर के विकास और आपूर्ति के लिए विक्रेताओं का चयन करने की प्रक्रिया से हैरान थी। ठेकेदारों का चयन कैसे करें? यह उन कंपनियों के कुछ संकेतक-स्तरों को लागू करने के लिए आवश्यक था, जो उन लोगों को अलग करने के लिए जो बेतरतीब ढंग से काम करते हैं। आदर्श रूप से, यह संकेतक केवल एक संख्या है: 1,2,3,4,5 ... स्तर 5 की एक कंपनी स्तर 3 की कंपनी से बेहतर है, इसलिए हम स्तर 5 की कंपनी के साथ काम करते हैं। तो CMMI (क्षमता परिपक्वता मॉडल एकीकरण) मानक दिखाई दिया। EPAM का 4 वां स्तर (5 में से) है, जिसका अर्थ है कि यह 2 या 3 के मुकाबले बाजार पर अधिक आकर्षक लगता है।



किसी तरह मुझे सरकारी एजेंसियों के लिए इंटरनेट परियोजनाओं के विकास से निपटना पड़ा। यह व्यवसाय आसान नहीं है और इसमें बहुत सारे जोखिम शामिल हैं। परिणाम अक्सर किसी विशेष अधिकारी के साथ स्थापित संबंधों की गुणवत्ता पर निर्भर करता था। लेकिन अगर उन्होंने इसे बदल दिया - लिखित उत्पाद को कचरे में फेंकना संभव था - उसके डिप्टी ने फिर से एक अजीब मांग की। एकमात्र तरीका यह है कि परियोजना में आवश्यकताओं और प्रत्येक आंदोलन को स्पष्ट रूप से ठीक किया जाए। फिर भी, मैंने GOSTs के अनुसार TK लिखा, जिससे अधिकारियों को खुशी हुई।



तो हमें ऐसे मानक की आवश्यकता क्यों है?

गुणवत्ता बार

वर्तमान में, सरकारी एजेंसियों और एजेंसियों की कई इंटरनेट परियोजनाओं की गुणवत्ता प्लिंथ से कम है। यह कोई रहस्य नहीं है कि इन साइटों को विकसित किया गया था जैसा कि उन्हें होना चाहिए, उन्हें अपडेट करने की प्रक्रिया मौजूद नहीं है, और यह सूचना सुरक्षा के बारे में बात करने के लायक नहीं है। कभी-कभी काम खराब सिस्टम व्यवस्थापक के लिए गिर जाता है।



दस्तावेज़ W3C मानकों पर लागू होता है, जो वेब मानकों, साथ ही प्रयोज्य मानकों की एक संख्या को बहुत कृपया करना चाहिए।

आवश्यकताओं का विवरण

सकारात्मक बात यह है कि मानक स्तर पर कई आवश्यकताओं का गठन पहले ही किया जा चुका है। इसका सीधा मतलब यह है कि जब संदर्भ की शर्तों को खींचते हैं, तो आप इस मानक के प्रावधानों का उल्लेख कर सकते हैं। जब मैं बेलारूसी परियोजनाओं के लिए विश्लेषिकी में लगा हुआ था, तो मेरे पास वास्तव में ऐसा कोई मानक नहीं था।

काम की स्वीकृति

यह कोई रहस्य नहीं है कि सरकारी ग्राहकों के लिए काम करते समय काम की स्वीकृति हमेशा एक समस्या है। इसके दो कारण हैं:

• अक्सर काम की स्वीकृति के लिए पर्याप्त योग्य विशेषज्ञ नहीं होते हैं। यह साबित करने के लिए कि आप सही हैं, बहुत मुश्किल है। नतीजतन, टीके में बहुत विस्तृत गुणवत्ता आवश्यकताओं को निर्धारित करना आवश्यक है।
• फैलाव आवश्यकताओं। यह महसूस करते हुए कि स्वीकृति के बाद अनुबंध बंद हो गया है, ग्राहक नई और नई आवश्यकताओं के माध्यम से धक्का देने की कोशिश कर रहा है।

तथ्य यह है कि अगर गैर-कार्यात्मक आवश्यकताओं को टीओआर में स्पष्ट रूप से स्पष्ट नहीं किया गया है, तो ग्राहक उद्योग मानकों के लिए अपील कर सकता है। यदि हम यूरोपीय संघ में रहते हैं, तो अपील आईएसओ मानकों के अनुरूप होगी। और यहाँ यह एक छोटा सा प्रतीत नहीं होगा।



सामान्य तौर पर, संक्षेप में, ऐसा मानक कई प्रश्नों को हटा देता है और अधिकारियों द्वारा निर्णय लेने का आधार निर्धारित करता है। और अगर मानक उच्च पर्याप्त गुणवत्ता के उत्पादन में प्राप्त किया जाता है, तो वाणिज्यिक साइटों को विकसित करते समय इसे संदर्भित करने के लिए समझ में आता है।



यह सुनना अजीब है कि इस तरह के मानक की शुरुआत के साथ, वेब डेवलपर्स को तंग करना होगा। :) सबसे पहले, आप पूरे लेबल को बंद कर सकते हैं, जो हम कहते हैं वह मानक के अनुसार कर रहा है - हमारे पास जाओ! दूसरे, इस मामले के लिए एक सामंजस्यपूर्ण विकास प्रक्रिया का निर्माण करना - यह मानक के साथ आसान है।



उसी समय, मैं यह नहीं कहना चाहता कि दस्तावेज़ सुंदर, उत्कृष्ट है और अपरिवर्तित स्वीकार किया जाना चाहिए। मैंने पूरे दस्तावेज को नहीं पढ़ा, केवल सर्गेई ने क्या कहा। मैंने जो पढ़ा है - बहुत सारी चीजें बहुत ज्यादा हैं। उसे जीवन का अधिकार है।



क्या बुरा है:

• गुणवत्ता परिभाषा का उपयोग। "पृष्ठ तत्वों को आसानी से पहचाना जाना चाहिए" - यह स्पष्ट नहीं है कि इसका क्या मतलब है आसानी से? मानकों और आवश्यकताओं में ऐसी भाषा से बचना चाहिए।
• फजी संरचना। उदाहरण के लिए, डिज़ाइन अनुभाग में सुरक्षा के बारे में। :)

यदि सामान्य पद्धतिविदों को दस्तावेज़ मिलता है, तो वे इन बारीकियों को सही करेंगे। सामान्य तौर पर, दिशा सकारात्मक है।