👳🏿 🚥 🚗 ईएसपीडी के साथ अनुभव 🙏🏼 🎨 🦇

परिचय

इस पाठ का मुख्य कार्य आपको यह बताना है कि एकीकृत कार्यक्रम प्रलेखन प्रणाली (UPRP) क्या है और इन मानकों को व्यवहार में कैसे लागू किया जाए। मैं इस बारे में बात करना शुरू करूंगा कि कौन से मानक मौजूद हैं और प्रत्येक सीईएसडी मानकों को व्यक्तिगत रूप से लागू करने के अनुभव के साथ समाप्त होते हैं।

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

यहां मैं केवल एक विषय पर ध्यान केंद्रित करना चाहता हूं जो एक प्रोग्रामर को घरेलू उद्यमों में, विशेष रूप से एक शोध संस्थान में - ईएसपीडी मानकों के एक सेट पर निपटना है। मैं खुद को यूनिफाइड रोड ट्रांसपोर्ट पॉलिसी का बहुत बड़ा पारखी नहीं मानता - ऐसे लोग हैं जो दशकों से इस पर काम कर रहे हैं, और वे मुझे ज़रूर सुधारेंगे। यह लेख उन लोगों के लिए "रोड मैप" की रूपरेखा को रेखांकित करने की कोशिश कर रहा है, जो सिर्फ तस्वीर में दिख रहे हैं।

मानकों

आइए एक संक्षिप्त जानकारी लें कि कौन से मानक मौजूद हैं (आईटी पर ध्यान केंद्रित करते हुए)।

अंतरराष्ट्रीय। विशिष्ट विशेषता - एक अंतरराष्ट्रीय संगठन द्वारा अपनाई गई। ऐसे संगठन का एक उदाहरण आईएसओ (मानकीकरण के लिए अंतर्राष्ट्रीय संगठन) है। इसके मानक का एक उदाहरण है: आईएसओ 2382-12: 1988 (परिधीय उपकरण)। आईएसओ और अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन (आईईसी, रूसी में - आईईसी) के संयुक्त मानक आम हैं: उदाहरण के लिए, आईएसओ / आईईसी 12207: 2008 (सॉफ्टवेयर जीवन चक्र);
क्षेत्रीय। विशिष्ट सुविधा - क्षेत्रीय मानकीकरण आयोग द्वारा अपनाया गया। उदाहरण के लिए, कई सोवियत GOSTs अब एक क्षेत्रीय मानक हैं, क्योंकि अंतरराज्यीय परिषद द्वारा अपनाया गया, जिसमें पूर्व सोवियत गणराज्यों में से कुछ शामिल हैं। इस सलाह के साथ, नए मानकों को अपनाया जाता है - और उन्हें GOST पदनाम भी प्राप्त होता है। उदाहरण: GOST 12.4.240-2013;
सार्वजनिक संघों के मानक; उदाहरण के लिए, वही आईईसी: आईईसी 60255;
राष्ट्रीय मानकों। रूस के लिए, ऐसे मानकों की शुरुआत में "GOST R" है। इसके तीन प्रकार हो सकते हैं:
1. अंतरराष्ट्रीय या क्षेत्रीय की सटीक प्रतियां। "स्व-लिखित" (राष्ट्रीय, स्वतंत्र रूप से लिखा गया) से अप्रभेद्य संकेत;
2. परिवर्धन के साथ अंतरराष्ट्रीय या क्षेत्रीय की प्रतियां। उन्हें अंतर्राष्ट्रीय सिफर के घरेलू मानक के सिफर से जोड़कर संकेत दिया जाता है, जिसे एक आधार के रूप में लिया गया था। उदाहरण के लिए: GOST R ISO / IEC 12207;
3. दरअसल, राष्ट्रीय मानक। उदाहरण के लिए, GOST R 34.11-94।

प्रत्येक स्तर पर और प्रत्येक संगठन में नोटेशन सिस्टम अलग-अलग हैं, प्रत्येक मामले के लिए अलग से समझना आवश्यक होगा। यह समझने के लिए कि आपकी आंखों के सामने किसका मानक है, आप एक धोखा पत्र का उपयोग कर सकते हैं।

GOST

तो: मानक अंतरराष्ट्रीय, अंतरराज्यीय (क्षेत्रीय) और राष्ट्रीय हैं। GOST, जैसा कि हमें पता चला है, एक क्षेत्रीय मानक है। मेरी राय में, संकेतन में GOSTs एक नहीं बल्कि जटिल है। यह GOST R 1.5-2004 में पूरी तरह से सेट है, मैं इसे नेविगेट करने के लिए एक न्यूनतम दे दूंगा। सबसे पहले, GOST के पदनाम और इसके वर्गीकरण को भेद करना आवश्यक है। एक पदनाम, मोटे तौर पर बोल रहा है, एक मानक के लिए एक अद्वितीय पहचानकर्ता है। क्लासिफायर कोड एक सहायक कोड है जो आपको एक मानक खोजने या यह निर्धारित करने में मदद करता है कि यह किस क्षेत्र की विशेषज्ञता का है। कई वर्गीकरण हो सकते हैं, मुख्य रूप से दो का उपयोग किया जाता है: केजीएस (राज्य मानकों का वर्गीकरण) और इसके उत्तराधिकारी एसीएस (मानकों के सभी-रूसी वर्गीकरणकर्ता)। उदाहरण के लिए: "GOST R 50628-2000" मानक का पदनाम है। पदनाम केवल यह समझता है कि इसे 2000 में अपनाया गया था। इसके पास ACS "33.100; 35.160" के लिए एक कोड है: i.e. "33" - अनुभाग "दूरसंचार, ऑडियो, वीडियो", "100" - उपधारा "विद्युत चुम्बकीय संगतता"। हालांकि, यह क्लासिफायर 35.160 ब्रांच का भी है। "35" - "सूचना प्रौद्योगिकी। कार्यालय मशीनें "," 160 "-" माइक्रोप्रोसेसर सिस्टम .... "। और CSC के अनुसार, इसका कोड "E02" है, जिसका अर्थ है "E" - "इलेक्ट्रॉनिक इंजीनियरिंग, रेडियो इलेक्ट्रॉनिक्स और संचार", "0" - "सामान्य नियम और मानदंड इलेक्ट्रॉनिक इंजीनियरिंग, रेडियो इलेक्ट्रॉनिक्स और संचार", आदि।

यदि मानक का पदनाम ज्ञात है, तो आप सीजीएस और एसीएस के लिए इसके कोड प्राप्त कर सकते हैं, उदाहरण के लिए, इस समझदार साइट पर ।
इसलिए, GOST के पदनामों पर वापस जाएं। दो विकल्प हो सकते हैं:

मानक मानकों की एक श्रृंखला को संदर्भित करता है। इस मामले में, मानक की श्रेणी के सूचकांक (उदाहरण के लिए, GOST, GOST R या GOST RV) के बाद, एक श्रृंखला कोड, एक बिंदु और श्रृंखला के अंदर मानक का एक पदनाम है। एक श्रृंखला के भीतर मानकों को नामित करने के नियम श्रृंखला के नियमों द्वारा स्थापित किए जाते हैं। उदाहरण के लिए: GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77;
मानक मानकों की एक श्रृंखला पर लागू नहीं होता है। फिर श्रेणी के सूचकांक के बाद बस मानक की क्रम संख्या, एक पानी का छींटा और गोद लेने का वर्ष है। उदाहरण के लिए, GOST R 50628-2000।

इसलिए, यदि यह काफी सरल है - तो GOST पदनाम या तो सिर्फ एक क्रमिक संख्या, एक डैश, एक वर्ष या एक श्रृंखला संख्या, एक बिंदु और आगे श्रृंखला पर निर्भर करता है। वास्तव में, सब कुछ अधिक जटिल है (उदाहरण के लिए, आप GOST 11326.19-79 जैसी किसी चीज से मिल सकते हैं, और यह 11326 श्रृंखला बिल्कुल भी नहीं होगी - लेकिन प्रोग्रामर को इसकी बहुत कम आवश्यकता होती है। विवरण के लिए, GOST R 1.5-2004 देखें)।

ESPD

ईएसपीडी GOSTs की ऐसी श्रृंखला में से एक है, नंबर 19. यानी। यूनिफाइड रोड ट्रांसपोर्ट रेगुलेशन से संबंधित सभी मानक उपसर्ग "19." से शुरू होते हैं: उदाहरण के लिए, GOST 19.106-78। यह "एकीकृत सॉफ्टवेयर प्रलेखन प्रणाली" के लिए खड़ा है। अन्य श्रृंखलाएं हैं:

GOST ESKD (डिजाइन प्रलेखन के लिए एकीकृत प्रणाली, उपसर्ग "2.");
GOST ESTD (तकनीकी दस्तावेज की एकीकृत प्रणाली, उपसर्ग "3.");
GOST R, विकास के लिए प्रणाली और उत्पादन में उत्पाद डालते हुए, उपसर्ग "15.";
GOST RV, आयुध और सैन्य उपकरण। विकास और उत्पादन में उत्पादों को लगाने की प्रणाली, उपसर्ग "15.";
GOST, ACS के लिए तकनीकी दस्तावेज की प्रणाली, उपसर्ग "24.";
GOST, स्वचालित सिस्टम के लिए मानकों का एक सेट, उपसर्ग "34."।

इसलिए, ESPD में सॉफ़्टवेयर विकास में उपयोग किए जाने वाले मानकों का एक सेट होता है। इसके अलावा, व्यापार पर विनियमन के एकीकृत ढांचे से प्रत्येक मानक के लिए, गैर-स्पष्ट मामलों के लिए एक संक्षिप्त विवरण और स्पष्टीकरण दिया जाता है।

19.001-77। सामान्य प्रावधान

ESPD श्रृंखला में पदनाम मानकों के असाइनमेंट के लिए नियमों का वर्णन करता है। व्यावहारिक जीवन में जरूरत नहीं है।

19.102-80। एल्गोरिदम और कार्यक्रमों की योजनाएं। निष्पादन के नियम।

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

19.003-80। एल्गोरिदम और कार्यक्रमों की योजनाएं। ग्राफिक सम्मेलनों

फ़्लोचार्ट के अनुमत प्रकार के तत्वों के ग्राफिक पदनाम दिए गए हैं। यदि फ़्लोचार्ट का उपयोग किया जाता है तो उपयोगी है।

19.004-80। नियम और परिभाषाएँ।

स्कन्ती शब्दावली। दिलचस्प से - कार्यक्रम और परिचालन दस्तावेजों की औपचारिक परिभाषाएं शामिल हैं।

19.005-85। एल्गोरिदम और कार्यक्रमों की पी-योजनाएं

लगभग भूली हुई भाषा। एक समय में, पी-सर्किट का व्यापक रूप से रॉकेट और अंतरिक्ष उद्योग में उपयोग किया गया था, जो प्रक्षेपण नियंत्रण कार्यक्रम और लॉन्च सिमुलेशन लिखने के लिए वास्तविक मानक बन गया था। हालाँकि, अब यह भाषा पूरी तरह से अनजान है। अपने काम में, मैंने कभी भी पी-सर्किट का सामना नहीं किया। हालांकि, ब्लॉक आरेखों पर उनके महत्वपूर्ण फायदे हैं: वे कॉम्पैक्ट हैं, गैर-रेखीय एल्गोरिदम को देखने के लिए उपयुक्त हैं (उदाहरण के लिए, C ++ में कक्षाएं) या डेटा संरचनाएं। इसी समय, इंटरनेट पर उनके बारे में व्यावहारिक रूप से कोई जानकारी नहीं है: यह और यह साइटें मुझे उपयोगी लगीं। किसी भी मामले में, अगर अब मुझे प्रोग्राम प्रलेखन में एल्गोरिथ्म आरेख सम्मिलित करना था, तो मैं पी-योजनाएं चुनूंगा, और ब्लॉक-स्कीम नहीं।

19.101-77। कार्यक्रमों और कार्यक्रम दस्तावेजों के प्रकार

इसमें अपने कोड के प्रकार के पत्राचार की एक तालिका है, साथ ही साथ संचालन और सॉफ्टवेयर में दस्तावेजों के प्रकारों का विभाजन भी है। जटिल और घटक की अवधारणा पेश की गई है। अधिक उपयोगी कुछ भी नहीं है।

19.102-77। विकास के चरण

एक महत्वपूर्ण और आवश्यक मानक, जो दस्तावेजों के प्रकारों का वर्णन करता है और प्रोग्राम के प्रकारों के कोड देता है। यह मानक (19.103-77 के साथ) ABVG.10473-01 32 01-1 जैसे दस्तावेजों के पदनाम "अनावरण" करने के लिए एक कुंजी है।
मानक एक कॉम्प्लेक्स और एक घटक की अवधारणा का परिचय देता है (कई उद्यम तीसरे प्रकार को जोड़ते हैं - एक सेट, जब यह असंबंधित सॉफ़्टवेयर तत्वों की बात आती है), तो एक अलगाव दिया जाता है: कौन से दस्तावेज़ चालू हैं, जो नहीं हैं।
आपको तालिका 4 का सावधानीपूर्वक उल्लेख करना चाहिए, जो यह दर्शाता है कि विकास के किस चरण में कौन सा दस्तावेज़ किया गया है। विकास चरणों को आमतौर पर डिजाइन और विकास कार्य के कार्यान्वयन के लिए मानकों में विनियमित किया जाता है, और यह यह भी इंगित करता है कि प्रत्येक चरण में ग्राहक को क्या दस्तावेज प्रस्तुत किए जाने चाहिए।

19.102-77। विकास के चरण

मेरी स्मृति में, यह मानक कभी लागू नहीं किया गया है: जो टीटीजेड में किस चरण में और किस रिपोर्ट में लिखा गया है, वह क्या करता है या GOSTs को एक संदर्भ दिया जाता है, जहां इसे अधिक स्पष्ट रूप से लिखा जाता है (उदाहरण के लिए, GOST RV 15.203)। एक ही समय में, एक शुरुआत के लिए, वह अपनी संक्षिप्तता में ओसीडी के मुख्य चरणों में काम का एक अच्छा सारांश देता है।

19.103-77। कार्यक्रमों और कार्यक्रम के दस्तावेजों के पदनाम

यह मुख्य रूप से सीखने की जरूरत है कि ऊपर दिए गए दस्तावेज़ों के पदनाम कैसे पढ़ें। हालांकि, संकेतन योजना को समझना उपयोगी है जब आपको मानक कार्य के दायरे से परे जाना पड़ता है: उदाहरण के लिए, याद रखें कि 90 के बाद के कोड वाले दस्तावेज़ उपयोगकर्ता-परिभाषित हैं, अर्थात्। किसी भी। मेरे व्यवहार में, हमने दस्तावेज़ 93 जारी किया, जिसे "कार्यक्रम प्रलेखन का विवरण", 96 दस्तावेज़ - "विधानसभा निर्देश" कहा गया।
सामान्य वाक्यांश "निष्पादन विकल्प" एकीकृत सड़क परिवहन प्रणाली में अनुपस्थित है, और इसे "संशोधन संख्या" द्वारा प्रतिस्थापित किया गया है। एक तरफ, यह पूरी तरह से सही नहीं है: कार्यक्रम के विकास को ट्रैक करने के लिए संपादकीय संख्या की कल्पना की गई थी: पहला, पहला संस्करण सामने आता है, फिर, उदाहरण के लिए, शोधन के बाद, दूसरा। लेकिन व्यवहार में, जब आपको कई ऑपरेटिंग सिस्टम (क्रॉस-प्लेटफ़ॉर्म सॉफ़्टवेयर) के लिए सॉफ़्टवेयर संस्करण जारी करने की आवश्यकता होती है, तो कोई अन्य तरीका नहीं है। अधिक सटीक रूप से, वहाँ है, लेकिन यह गलत है: प्रत्येक ओएस के लिए एक संस्करण, अपने स्वयं के पदनाम को असाइन करें, और संग्रह में स्रोत कोड के साथ कई डिस्क डालें (OSes की संख्या के अनुसार), प्रलेखन के पूरे सेट को विकसित करें (वास्तव में प्रतिलिपि), आदि ... सरासर बेवकूफ और भ्रमित करने वाली गतिविधि। अपने स्वयं के संशोधन संख्या के प्रत्येक ओएस के लिए एक संस्करण असाइन करने के रूप में निर्णय आपको कुछ दस्तावेजों को सामान्य बनाने की अनुमति देता है।
ईएसपीडी एक प्रोग्राम के स्रोत कोड और "परिणाम" द्वारा विधानसभा परिणाम को दर्शाने के लिए कई प्रोग्रामर की शर्मिंदगी का उपयोग करता है। दस्तावेज़ "कार्यक्रम पाठ", 19.101-77 के अनुसार, पदनाम 12 है। यह आगे माना जाता है कि स्रोत कोड 12 01 के रूप में नामित है - अर्थात। 01 (प्रथम) प्रकार 12 का दस्तावेज़, और बायनेरिज़ - 12 02 के रूप में - अर्थात्। दूसरा दस्तावेज़ प्रकार 12 का है। कुछ मामलों में, प्रोग्राम बनाने के लिए अतिरिक्त टूल की आवश्यकता होती है - कंपाइलर, इंस्टॉलर जनरेटर आदि। यानी ऐसे कार्यक्रम जो वितरण में शामिल नहीं हैं, लेकिन विधानसभा के लिए आवश्यक हैं। समाधान उन्हें 12 03 के रूप में नामित कर सकता है - अर्थात। टाइप 12 का तीसरा दस्तावेज।

19.104-78। मुख्य शिलालेख

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

जैसा कि पहले ही उल्लेख किया गया है, अक्सर कंपनी डेवलपर के बारे में जानकारी का खुलासा नहीं करना चाहती है। LU पृथक्करण और इसका "निचोड़ना" इसे करने की अनुमति देता है (ESKD के विपरीत, दस्तावेज़ की शीट पर ESPD में कोई मुहर नहीं है, सभी जानकारी केवल LU में स्थानीयकृत है);
कई उद्यमों में मिश्रित दस्तावेज़ प्रबंधन का उपयोग किया जाता है: मूल दस्तावेजों को इलेक्ट्रॉनिक रूप में उद्यम के संग्रह में संग्रहीत किया जाता है, और उन पर एलयू (मूल हस्ताक्षर के साथ) - कागज में;

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

19.105-78। कार्यक्रम के दस्तावेजों के लिए सामान्य आवश्यकताएं

दस्तावेज़ की सामान्य संरचना पेश की जाती है, जिस तरह से इसे निष्पादित किया जाता है, उससे स्वतंत्र। यानी 1978 में वापस मानक में यह निर्धारित किया गया था कि एक दस्तावेज आवश्यक रूप से कागज नहीं हो सकता है। विशेष रूप से, सामग्री की अवधारणा पूरी तरह से इलेक्ट्रॉनिक दस्तावेजों के लिए पेश की गई है। कागजी कार्रवाई के लिए, उस समय आम, GOST 19.106-78 को अपनाया गया था।
वर्तमान में, इस मानक को बहुत कम ही एक्सेस किया जा सकता है: जब तक कि दस्तावेज़ के मुख्य भागों के आदेश को नहीं भुला दिया जाता है।

19.106-78। मुद्रित कार्यक्रम दस्तावेजों के लिए सामान्य आवश्यकताएं

ईएसपीडी का सबसे बड़ा मानक, केवल आर-योजनाओं के विवरण से हीन है। यह प्रलेखन की तैयारी में मुख्य कार्य मानक है। पाठ के डिजाइन, दस्तावेज़ की संरचना के तत्व, चित्र, सूत्र आदि के लिए नियमों का परिचय देता है। हालांकि, ESKD से संबंधित 2.106 के विपरीत, 19.106 काफी कम विस्तृत है, जो कई अनिश्चितताओं की ओर जाता है।
सबसे पहले, मानक वास्तव में लाइन रिक्ति और हेडर के बीच ऊर्ध्वाधर इंडेंटेशन की मात्रा को परिभाषित नहीं करता है। वह अंतराल के निर्धारण के लिए तीन नियमों का परिचय देता है: टाइप किए गए पाठ, मशीन और टाइपोग्राफिक के लिए।
टंकण पाठ टंकण पाठ है। पिछले एक के सापेक्ष अगली पंक्ति की पारी को तथाकथित "कैरिज ट्रांसफर" के साथ स्वचालित रूप से किया गया था - एक विशेष लीवर को स्थानांतरित करके अगली पंक्ति को प्रिंट करने के लिए संक्रमण। एक नियम के रूप में, अंतराल को मैन्युअल रूप से कागज फ़ीड शाफ्ट को बदलकर समायोजित किया जा सकता है, और एक "सेटिंग" थी जो आपको अंतराल मूल्य - एकल या डबल सेट करने की अनुमति देती है।
मशीन - यह सबसे अधिक संभावना है मुद्रित पाठ। लेकिन उसके लिए केवल एक संकेत है कि परिणाम माइक्रोफिल्मिंग के लिए उपयुक्त होना चाहिए। यह 13.1.002-2003 के लिए एक अंतर्निहित संदर्भ है, जो दुर्भाग्य से, लाइन रिक्ति (और, न्यूनतम फ़ॉन्ट ऊंचाई) केवल हस्तलिखित दस्तावेजों के लिए सेट करता है (धारा 4.2.5)।
टाइपोग्राफिक - एक प्रिंट शॉप में टाइप किया गया टेक्स्ट। मानक को अपनाने के वर्ष को देखते हुए, सबसे अधिक संभावना है कि हम किस बारे में बात कर रहे हैं
[ लेटरप्रेस , जहां लाइन स्पेसिंग का उपयोग किए गए अक्षरों द्वारा निर्धारित किया गया था। मैं मुद्रण व्यवसाय का विशेषज्ञ नहीं हूं, और अब भर्ती के तरीकों के बारे में बहुत कम जानकारी है।
अंत में उपयोग करने के लिए कौन सा अंतराल अक्सर स्थानीय नियामक नियंत्रण या सेवा स्टेशनों द्वारा निर्धारित किया जाता है। विशिष्ट मूल्य डेढ़ रिक्ति और 14 फ़ॉन्ट आकार हैं।
अक्सर ऐसे कई प्रश्न होते हैं कि किसी दस्तावेज़ को कैसे संरचित किया जाता है। 19.106 का मानना है कि पूरे दस्तावेज़ को अनुभागों, उपखंडों, पैराग्राफ और उप-अनुच्छेदों में विभाजित किया गया है। उन सभी (अनुभाग और उपधारा को छोड़कर) में हेडिंग हो सकती है या नहीं भी हो सकती है। इस मामले में:

"दस्तावेज़ की सामग्री में एक शीर्षक के साथ वर्गों, उपखंडों, पैराग्राफ और उप-अनुच्छेदों की संख्या शामिल है" (पैराग्राफ 2.1.4)। यह एक सीधा संकेत है कि उप-अनुच्छेद में एक शीर्षक हो सकता है और सामग्री की तालिका में शामिल किया जा सकता है;
"यह अनुभाग और उपधारा के शीर्षों के बीच पाठ को रखने की अनुमति है, उपधारा और पैराग्राफ के शीर्षकों के बीच।" यह ध्यान रखना महत्वपूर्ण है कि अनावश्यक पाठ केवल शीर्षकों के बीच हो सकता है, और केवल शीर्ष 2 स्तरों पर।

, : , , “ ”, , , “. N”.
“”, . , : “, , . “ , , ? . — .
. 1.5.68. , , . , . , . , , , 1.5-2012, … . 1.5-2002 , 1.5-2004 . .
. , , . , , , .. .
, . , 5 , :

;
(, , );
.
, , . , — — , — , — .

.

ईएसपीडी के साथ अनुभव

परिचय

मानकों

GOST

ESPD

19.001-77। सामान्य प्रावधान

19.102-80। एल्गोरिदम और कार्यक्रमों की योजनाएं। निष्पादन के नियम।

19.003-80। एल्गोरिदम और कार्यक्रमों की योजनाएं। ग्राफिक सम्मेलनों

19.004-80। नियम और परिभाषाएँ।

19.005-85। एल्गोरिदम और कार्यक्रमों की पी-योजनाएं

19.101-77। कार्यक्रमों और कार्यक्रम दस्तावेजों के प्रकार

19.102-77। विकास के चरण

19.102-77। विकास के चरण

19.103-77। कार्यक्रमों और कार्यक्रम के दस्तावेजों के पदनाम

19.104-78। मुख्य शिलालेख

19.105-78। कार्यक्रम के दस्तावेजों के लिए सामान्य आवश्यकताएं

19.106-78। मुद्रित कार्यक्रम दस्तावेजों के लिए सामान्य आवश्यकताएं

More articles: