आज हम परियोजना प्रलेखन के लिए घरेलू मानकों के बारे में बात करेंगे। ये मानक व्यवहार में कैसे काम करते हैं, वे क्यों खराब हैं और क्या अच्छे हैं। सार्वजनिक और गंभीर निजी ग्राहकों के लिए प्रलेखन विकसित करते समय, हमारे पास आमतौर पर कोई विकल्प नहीं होता है - मानकों के अनुपालन टीके के दस्तावेजीकरण की आवश्यकताओं में शामिल है। व्यवहार में, मुझे मानकों की संरचना की गलतफहमी के विभिन्न उदाहरणों से निपटना था, दस्तावेजों में क्या होना चाहिए और इन दस्तावेजों की आवश्यकता क्यों है। नतीजतन, कभी-कभी तकनीकी लेखकों, विश्लेषकों, और विशेषज्ञों की कलम के नीचे से ऐसे मोती निकलते हैं कि यह स्पष्ट नहीं है कि वे किस चेतना की स्थिति में लिखे गए थे। लेकिन वास्तव में, सब कुछ काफी सरल है। Habré में खोज ने इस विषय पर अधिक या कम समग्र सामग्री के लिंक वापस नहीं किए, इसलिए मैं इस कष्टप्रद अंतराल को भरने का प्रस्ताव करता हूं।
दस्तावेज़ीकरण मानक क्या हैं?
प्रश्न में 34 श्रृंखला में, प्रलेखन के लिए केवल 3 मुख्य मानक हैं:
GOST 34.602-89 स्वचालित प्रणाली के निर्माण के लिए संदर्भ की शर्तेंटीके के विकास के लिए सबसे प्रिय और लोकप्रिय मानक। केवल एक चीज जिसे आपको नहीं भूलना चाहिए वह यह है कि यह श्रृंखला के अन्य मानकों के साथ कसकर जुड़ा हुआ है और अगर आपको इस मानक के अनुसार किए गए कार्य का विवरण प्राप्त हुआ है, तो अन्य मानकों का पालन करना अत्यधिक उचित है, भले ही कोई प्रत्यक्ष आवश्यकताएं न हों। कम से कम सामान्य विचारधारा के संदर्भ में (जिसके बारे में नीचे)
GOST 34.201-89 स्वचालित सिस्टम बनाते समय दस्तावेजों की पूर्णता और पदनामयह एक मूल दस्तावेज है जो GOST 34 दस्तावेज की पूरी सूची प्रदान करता है, दस्तावेजों की कोडिंग के लिए सिफारिशें, परियोजना दस्तावेजों के किस चरण से संबंधित हैं (चरण GOST 34.601-90 में वर्णित हैं), और उन्हें एक दूसरे के साथ कैसे जोड़ा जा सकता है।
वास्तव में, यह मानक टिप्पणियों के साथ एक बड़ी तालिका है। उपयोग में आसानी के लिए इसे एक्सेल में चलाया जा सकता है।
RD 50-34.698-90 स्वचालित सिस्टम। दस्तावेज़ सामग्री आवश्यकताएँएक स्वैच्छिक मानक, परियोजना दस्तावेजों की सामग्री का वर्णन करते हुए विस्तार की डिग्री के साथ। सूचकांक के रूप में, उपरोक्त GOST 34.201-89 का उपयोग किया जाता है।
आरडी 50-34.698-90 के मानक के लिए, इसके प्रावधानों के कई सवाल और व्याख्याएं हैं, जो कि उनकी अस्पष्टता के कारण अक्सर ग्राहक और ठेकेदार या परियोजना टीम के सदस्यों द्वारा अलग-अलग तरीके से समझे जाते हैं। लेकिन, दुर्भाग्य से, हमारे पास और अधिक ठोस कुछ भी नहीं है।
अब पेशेवरों और मानकों के विपक्ष पर विचार करें, पारंपरिक रूप से विपक्ष के साथ शुरू।
मानक के विपक्ष
मुख्य माइनस सभी के लिए स्पष्ट है - मानक पुराने हैं। उनके पास एक स्वचालित प्रणाली की वास्तुकला का एक पुराना दृश्य है। उदाहरण के लिए:
- दो-स्तरीय अनुप्रयोग जिसमें क्लाइंट प्रोग्राम और DBMS सर्वर (तीन या अधिक "स्तरीय" अनुप्रयोग, कोई वेबलॉग या BBoss शामिल नहीं हैं)
- डेटाबेस तालिकाओं की संरचना, जैसा कि वर्णित है, तार्किक डेटा मॉडल (तथ्य यह है कि आवेदन और डेटाबेस के बीच कुछ हाइबरनेट हो सकता है, का एक विचार देगा, तो यह एक बुरा अतिरिक्त लग रहा था)
- उपयोगकर्ता इंटरफ़ेस सिंगल-विंडो है (क्या यह वास्तव में अलग है? और "ब्राउज़र" क्या है?)
- सिस्टम में कुछ रिपोर्टें हैं, उनमें से सभी कागज हैं और एक मैट्रिक्स प्रिंटर पर मुद्रित हैं
- विकास के तहत कार्यक्रम "सूचना प्रसंस्करण समस्या" को हल करने पर केंद्रित है, जिसमें एक स्पष्ट इनपुट और आउटपुट है और अत्यधिक विशिष्ट है। सूचना प्रसंस्करण का आधार "एल्गोरिथ्म" है। कभी-कभी कई "एल्गोरिदम" होते हैं। (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग ने तब केवल अपने पहले कदम उठाए और गंभीरता से विचार नहीं किया गया)।
- डेटाबेस व्यवस्थापक समझता है कि तालिकाओं में कौन सी जानकारी है और संपादन प्रणाली निर्देशिकाओं में सक्रिय रूप से शामिल है (क्या 50 अनुप्रयोगों के लिए वास्तव में एक DBMS सर्वर है?)
तदनुसार, मानक में कलाकृतियाँ हैं, जैसे निम्नलिखित:
5.8. ()
50-77 .
दस्तावेज़ का अर्थ यह है कि सोवियत उद्यमों ने तथाकथित "प्रिंटिंग साइट्स" का उपयोग किया था, जहां डॉट-मैट्रिक्स हाई-स्पीड प्रिंटर थे, ड्राइवर, जिसके लिए इंजीनियर खुद अक्सर लिखते थे। इसलिए, उन्हें सभी दस्तावेजों के एक रजिस्टर को बनाए रखना था जो मुद्रित करने के लिए आवश्यक थे ताकि यह सुनिश्चित हो सके कि मुद्रित दस्तावेज़ दिखेंगे।
एक "वीडियो फ्रेम" भी एक दस्तावेज है जो एक पाठ प्रदर्शन पर प्रदर्शित किया गया था। प्रदर्शनों ने हमेशा वांछित पात्रों और क्षैतिज रूप से वर्णों की आवश्यक संख्या और लंबवत रेखाओं का समर्थन नहीं किया (और ग्राफिक्स बिल्कुल भी समर्थित नहीं थे)। इसलिए, यहां, सभी ऑन-स्क्रीन दस्तावेज़ों के रूपों को अतिरिक्त रूप से समन्वित करना आवश्यक था।
अब शब्द "मशीनोग्राम", "वीडियो फ्रेम", "एटीएसपीयू" हमें कुछ भी नहीं बताते हैं। मैंने उन्हें उपयोग में नहीं पाया, हालांकि मैंने 90 के दशक में एक विशेष संस्थान से स्नातक किया था। यह विंडोज 3.1, वीजीए डिस्प्ले, तीन-इंच फ्लॉपी डिस्क और पहले घरेलू इंटरनेट साइटों की उपस्थिति का समय था। लेकिन मानक में ये शब्द हैं, और ग्राहक कभी-कभी उन्हें GOST 34.201-89 के अनुसार प्रलेखन का पूरा सेट प्रदान करने की मांग करता है। इसके अलावा, टीके में इस तरह के शब्द एक मंत्रालय से दूसरे तक भटकते हैं और एक प्रकार का अलिखित टेम्पलेट बन गए हैं जिसमें मूल भाग को संचालित किया गया है।
इसलिए परियोजना में बेवकूफी शीर्षक "दस्तावेज़ के रूप का चित्र (वीडियो फ्रेम)" के साथ होना चाहिए और खाली नहीं होना चाहिए।
मानक में क्या अच्छा है?
कोई भी मानक पहले से ही अच्छा है क्योंकि यह ग्राहक और ठेकेदार को एक ही भाषा बोलने की अनुमति देता है और गारंटी देता है कि कम से कम ग्राहक के पास प्रेषित परिणामों के लिए "दावे" नहीं होंगे।
और GOST 34 मानक भी अच्छे हैं क्योंकि वे स्मार्ट लोगों द्वारा संकलित किए गए थे, वर्षों से लुढ़के हुए थे और उनका एक स्पष्ट लक्ष्य है - जटिल अमूर्त इकाई का वर्णन करने के लिए कि कोई भी एसीएस कागज पर पूरी तरह से यथासंभव प्रतिनिधित्व करता है।
जब आपको पश्चिमी ठेकेदारों के लिए कार्य को सही ढंग से निर्धारित करने की आवश्यकता होती है जिन्होंने हमारे GOSTs के बारे में कभी नहीं सुना है, तो आप इन मानकों पर भी भरोसा कर सकते हैं, और उनकी सामग्री, शब्दार्थ घटक पर अधिक सटीक रूप से। क्योंकि, मैं दोहराता हूं, सूचना की पूर्णता की गारंटी बहुत कुछ है। कोई फर्क नहीं पड़ता कि हम अपने व्यावसायिकता के उच्च स्तर के साथ खुद का मनोरंजन करते हैं, हम अपनी आवश्यकताओं में प्राथमिक चीजों को शामिल करना भूल सकते हैं, जबकि वही GOST 34.602-89 "सब कुछ" याद रखता है। यदि आपको समझ में नहीं आता है कि पश्चिमी ठेकेदारों के काम का परिणाम कैसा दिखना चाहिए, तो दस्तावेज़ीकरण की आवश्यकताओं और अनुशंसित वर्गों को देखें। मैं आपको विश्वास दिलाता हूं, यह बेहतर नहीं है कि इसके साथ आओ! सबसे अधिक संभावना है, हमारे मानकों के पश्चिमी एनालॉग हैं, जिसमें सब कुछ पूर्ण, अधिक आधुनिक और बेहतर हो सकता है। दुर्भाग्य से, मैं उनसे परिचित नहीं हूं, क्योंकि अभी तक एक भी मामला नहीं हुआ है कि हमारे GOSTs पर्याप्त नहीं होंगे।
आप इस तथ्य पर हंस सकते हैं कि मानकों के रचनाकारों को जावा या .NET के बारे में कुछ नहीं पता था, एचडी मॉनिटर और इंटरनेट के बारे में, लेकिन मैं उनके पेशेवर समुदाय के लिए उनके काम के पैमाने और इसके मूल्य को कम करके आंकने की सलाह नहीं दूंगा।
GOST श्रृंखला 34 के अनुसार प्रलेखन मानकों को कैसे पढ़ें और समझें
मानक सभी दस्तावेजों को दो अक्षों में विभाजित करता है - समय और विषय क्षेत्र। यदि आप GOST 34.201-89 में तालिका 2 को देखते हैं, तो आप इस विभाजन (कॉलम "निर्माण की अवस्था" और "परियोजना का हिस्सा" को स्पष्ट रूप से देख सकते हैं)
एसीएस बनाने के चरण
निर्माण के चरणों को GOST 34.601-90 में परिभाषित किया गया है। तीन उन्हें प्रलेखित करने के लिए प्रासंगिक हैं:
- प्रारंभिक डिजाइन (EP)
- तकनीकी परियोजना (टीपी)
- कार्य प्रलेखन का विकास (आरडी)
प्रारंभिक डिजाइन संदर्भ की शर्तों के चरण का अनुसरण करता है और प्रारंभिक डिजाइन निर्णयों को विकसित करने का कार्य करता है।
तकनीकी परियोजना सभी कोणों से भविष्य की प्रणाली का वर्णन करती है। टीपी चरण के दस्तावेज, पढ़ने के बाद, प्रस्तावित दृष्टिकोण, विधियों, वास्तु और तकनीकी समाधानों में पूरी स्पष्टता को पीछे छोड़ देना चाहिए। अगले चरण में, दृष्टिकोणों का वर्णन करने और तकनीकी समाधानों को सही ठहराने में बहुत देर हो जाएगी, ताकि पी चरण कार्य के सफल समापन की कुंजी है, क्योंकि चरण पी के दस्तावेजों में टीओआर की आवश्यकताओं की पूरी विविधता परिलक्षित होनी चाहिए। चरण पी में सिस्टम बिल्कुल भी मौजूद नहीं हो सकता है।
काम के प्रलेखन सफल तैनाती, कमीशन और नई प्रणाली के आगे संचालन के लिए करना है। ये चरण P के विपरीत शारीरिक रूप से विद्यमान संस्थाओं का वर्णन करते हुए बहुत विशिष्ट जानकारी वाले दस्तावेज हैं, जहां भविष्य की भव्यता का वर्णन किया गया है।
एसीएस के निर्माण के लिए डिजाइन प्रलेखन के भाग (खंड)
विषय क्षेत्र को "संपार्श्विक" में विभाजित किया गया है। प्रथमदृष्टया ऐसा लगता है कि इस तरह का विभाजन बेमानी और अनावश्यक है। लेकिन जब आप इस टूलकिट के साथ काम करना शुरू करते हैं, तो इसमें निहित विचारधारा धीरे-धीरे आती है।
GOST द्वारा संकलित स्वचालित प्रणाली, हार्डवेयर, सॉफ्टवेयर और संचार चैनलों का एक संयोजन है जो कुछ एल्गोरिदम के अनुसार विभिन्न स्रोतों से आने वाली सूचनाओं को संसाधित करता है और दस्तावेजों, डेटा संरचनाओं, या नियंत्रण क्रियाओं के रूप में प्रसंस्करण परिणाम प्रदान करता है। सरलतम ऑटोमेटन का आदिम मॉडल।इस "ऑटोमेटन" का पूरी तरह से वर्णन करने के लिए, निम्न अनुभाग बनाए गए थे (जैसा कि ड्राइंग में):
गणितीय समर्थन (एमओ) सवालों के जवाब: "ब्लैक बॉक्स" के अंदर क्या तर्क है? इन एल्गोरिदम को क्यों चुना गया, ठीक ऐसे सूत्र और ठीक ऐसे गुणांक?
सॉफ्टवेयर प्रोसेसर या डेटाबेस के बारे में कुछ भी नहीं जानता है। यह एक अलग सार क्षेत्र है, "वैक्यूम में गोलाकार घोड़ों का निवास"। लेकिन सॉफ्टवेयर विषय क्षेत्र, उर्फ रियल लाइफ के साथ बहुत कसकर जुड़ा हुआ है। उदाहरण के लिए, ट्रैफ़िक नियंत्रण प्रणालियों के लिए नियंत्रण एल्गोरिदम को ट्रैफ़िक पुलिस में ग्राहक द्वारा सहमत होने से पहले सहमति देने की आवश्यकता होती है। और फिर आप समझते हैं कि उन्हें एक अलग पुस्तक में क्यों आवंटित किया गया है। क्योंकि कोई भी ट्रैफ़िक पुलिस में दिलचस्पी नहीं लेता है कि ओएस किस पर एप्लिकेशन सर्वर काम करेगा, लेकिन बारिश या बर्फ में स्कोरबोर्ड पर क्या संकेत और गति सीमा होगी, यह बहुत दिलचस्प है। वे अपने हिस्से के लिए जिम्मेदार हैं, और कुछ और पर हस्ताक्षर नहीं करने जा रहे हैं। दूसरी ओर, जब उन्होंने हस्ताक्षर किए, तो सवाल के तकनीकी पक्ष के लिए कोई सवाल नहीं होगा - उन्होंने क्यों चुना, और अन्य डिस्प्ले या ट्रैफिक लाइट नहीं। "पूर्वजों" का ज्ञान केवल ऐसे व्यावहारिक मामलों में ही प्रकट होता है।
सूचना समर्थन (IO) । सिस्टम का एक और टुकड़ा। इस बार हमारे सिस्टम का ब्लैक बॉक्स पारदर्शी हो जाता है और हम इसमें मौजूद सूचनाओं को देखते हैं। मानव संचार प्रणाली के एक मॉडल की कल्पना करें जब अन्य सभी अंग अदृश्य होते हैं। यह कुछ इस तरह से सूचना का समर्थन है। यह अंदर और बाहर सूचना प्रवाह की संरचना और मार्गों का वर्णन करता है, सिस्टम में जानकारी का तार्किक संगठन, निर्देशिकाओं और कोडिंग सिस्टम का वर्णन (जिसने भी उत्पादन के लिए कार्यक्रम बनाए हैं वे जानते हैं कि वे कितने महत्वपूर्ण हैं)। मुख्य कथा टीपी मंच पर आती है, लेकिन कुछ "वेस्टेज" दस्तावेज "डेटाबेस निर्देशिका" आरडी चरण में आते हैं। यह स्पष्ट है कि पहले इसमें वही था जो शीर्षक में लिखा गया है। लेकिन आज, एक जटिल एकीकृत प्रणाली के लिए एक दस्तावेज बनाने की कोशिश करें जब सिस्टम के हिस्से के रूप में बहुत बार अपने रहस्यमय जानकारी भंडारण के साथ सब-सिस्टम खरीदे जाते हैं। मैं इस तथ्य के बारे में बात नहीं कर रहा हूं कि इस दस्तावेज़ की अब विशेष आवश्यकता नहीं है।
या यहाँ "मशीन स्टोरेज मीडिया का बुलेटिन" है। यह स्पष्ट है कि इससे पहले एक फिल्म के साथ चुंबकीय ड्रम या रीलों की संख्या थी। अब वहां क्या लाना है?
संक्षेप में, आरडी चरण में, सूचना समर्थन दस्तावेज एक दुर्भावनापूर्ण अशिष्टता है, क्योंकि उन्हें औपचारिक रूप से होना चाहिए, लेकिन उन्हें भरने के लिए कुछ भी नहीं है।
सॉफ्टवेयर । डिजाइन प्रलेखन का पसंदीदा हिस्सा। हाँ, यदि केवल इसलिए कि यह सिर्फ एक दस्तावेज है! और फिर, हर कोई समझता है कि वहां क्या दर्ज किया जाना चाहिए। लेकिन मैं, फिर भी, दोहराऊंगा।
इस दस्तावेज़ में, हमें MO में वर्णित एल्गोरिदम को निष्पादित करने के लिए उपयोग किए जाने वाले सॉफ़्टवेयर टूल के बारे में बात करनी चाहिए जो IE में वर्णित जानकारी को संसाधित करते हैं। यानी, यहां अन्य सेक्शन से डुप्लिकेट जानकारी की जरूरत नहीं है। यह सिस्टम की वास्तुकला, चयनित सॉफ्टवेयर प्रौद्योगिकियों के लिए तर्क, उनके विवरण (सिस्टम की सभी प्रकार की चीजें: प्रोग्रामिंग भाषा, रूपरेखा, OSes, आदि) देता है। इस दस्तावेज़ में हम यह भी वर्णन करते हैं कि कैसे सूचना प्रसंस्करण उपकरण आयोजित किए जाते हैं (संदेश कतार, भंडारण, बैकअप उपकरण, पहुंच समाधान, सभी प्रकार के एप्लिकेशन पूल, आदि)। मानक में इस दस्तावेज़ की सामग्री का विस्तृत विवरण है, जिसे कोई भी विशेषज्ञ समझेगा।
तकनीकी सहायता (TO) । डिजाइन प्रलेखन का कोई कम प्रिय हिस्सा नहीं। इन्द्रधनुषी तस्वीर केवल उन दस्तावेजों की प्रचुरता से विकसित होती है जिन्हें विकसित करने की आवश्यकता है। कुल मिलाकर, मानक के अनुसार, 22 दस्तावेजों को विकसित करना आवश्यक है, जिनमें से 9 टीपी चरण में हैं।
तथ्य यह है कि मानक कंप्यूटर हार्डवेयर और नेटवर्क, इंजीनियरिंग सिस्टम और यहां तक कि निर्माण भाग (यदि आवश्यक हो) सहित सभी तकनीकी सहायता का विवरण प्रदान करता है। और इस अर्थव्यवस्था को बड़ी संख्या में मानकों और मानक कृत्यों द्वारा विनियमित किया जाता है, विभिन्न संगठनों में समन्वित किया जाता है, और इसलिए यह सब कुछ भागों में विभाजित करने और भागों में समन्वय (संपादित) करने के लिए अधिक सुविधाजनक है। उसी समय, मानक आपको कुछ दस्तावेजों को एक-दूसरे के साथ संयोजित करने की अनुमति देता है, जो समझ में आता है कि क्या एक व्यक्ति पूरे गुच्छा से सहमत है।
यह भी मत भूलो कि गुणवत्ता मानकों के सेट से तात्पर्य तकनीकी दस्तावेजों के लेखांकन और भंडारण से है, और ग्राहक के बारे में हमारी "पुस्तकें" विवरण के विषय के आधार पर विभिन्न अभिलेखागार में जा सकती हैं। यह कुचल प्रलेखन के पक्ष में एक और तर्क है।
संगठनात्मक सहायता (जीएस) । तकनीशियन के लिए सामान्य रूप से जल्द से जल्द इस खंड के माध्यम से फिसलने के लिए सामान्य इच्छा, अपने आप में दबा हुआ, इसके विपरीत, मैं इसे और अधिक विस्तार से विचार करूंगा। चूंकि, सहकर्मियों, हाल ही में उन परियोजनाओं में बुरा रुझान रहा है जिन्हें इस खंड में स्पष्टीकरण की आवश्यकता है।
टीए चरण में, अनुभाग में केवल एक दस्तावेज शामिल है "
संगठनात्मक संरचना का विवरण ", जिसमें हमें ग्राहक को यह बताना होगा कि संगठनात्मक संरचना को बदलने के लिए उसे क्या तैयार करना चाहिए। अचानक, आपको अपने सिस्टम को संचालित करने, नए पदों को शुरू करने आदि के लिए एक नए विभाग को व्यवस्थित करने की आवश्यकता है।
आरडी चरण में, अन्य, अधिक दिलचस्प दस्तावेज दिखाई देते हैं कि मैं अलग से विचार करना चाहूंगा।
उपयोगकर्ता मैनुअल मुझे लगता है कि टिप्पणियाँ शानदार हैं।
कंप्यूटर एडेड डिजाइन की कार्यप्रणाली (तकनीक) । यदि आवश्यक हो, तो आप इस दस्तावेज़ में सॉफ़्टवेयर असेंबली प्रक्रिया, संस्करण नियंत्रण, परीक्षण आदि का विवरण डाल सकते हैं। लेकिन यह है कि अगर ToR में ग्राहक सॉफ्टवेयर को व्यक्तिगत रूप से इकट्ठा करना चाहता है। यदि उसे इसकी आवश्यकता नहीं है (और इसके लिए भुगतान नहीं करता है), तो आपका पूरा आंतरिक रसोईघर उसका व्यवसाय नहीं है, और इस दस्तावेज़ को करने की आवश्यकता नहीं है।
तकनीकी निर्देश । व्यवसाय प्रक्रियाओं को औपचारिक रूप देने के लिए फैशन के संबंध में, एक चालाक ग्राहक कभी-कभी इस दस्तावेज़ में एक ऑपरेशन सेवा के संचालन प्रक्रियाओं को रटना चाहता है। इसलिए, यह आवश्यक नहीं है।
व्यवसाय प्रक्रियाओं, भूमिका और नौकरी विवरण, कार्य विनियमों का विवरण - यह सब एक परिचालन दस्तावेज है, अर्थात संगठनात्मक और प्रशासनिक दस्तावेज। जो एक परामर्श परियोजना का एक उत्पाद है, जो, जैसा कि मैं समझता हूं, यह आपसे नहीं खरीदा गया था। और आपने आपसे एक तकनीकी परियोजना खरीदी और इसके लिए प्रलेखन भी तकनीकी है।
प्रौद्योगिकी मैनुअल ODS और उपयोगकर्ता पुस्तिका के बीच एक परत है। आरपी विस्तार से वर्णन करता है कि सिस्टम में कुछ क्रियाएं
कैसे करें। प्रौद्योगिकी मैनुअल कहता है
कि सिस्टम के संचालन से संबंधित कुछ मामलों में
किन कार्यों को करने की आवश्यकता है। मोटे तौर पर, एक प्रौद्योगिकी मैनुअल एक विशिष्ट स्थिति या भूमिका के लिए आरपी पर एक छोटी डाइजेस्ट है। यदि ग्राहक की कोई भूमिका नहीं है या यदि वह चाहता है कि आप भूमिकाएं और नौकरी की आवश्यकताएं बनाएं, तो दस्तावेज़ में सबसे बुनियादी भूमिकाएं शामिल करें, उदाहरण के लिए: ऑपरेटर, वरिष्ठ ऑपरेटर, व्यवस्थापक। "हम इसे पसंद नहीं करते" या "हम इसे पसंद नहीं करते" विषय पर ग्राहक की टिप्पणी, भूमिकाओं और नौकरी विवरणों की एक सूची के साथ होनी चाहिए। क्योंकि हम व्यावसायिक प्रक्रियाओं को
निर्धारित नहीं करते हैं। हम इन व्यावसायिक प्रक्रियाओं को
स्वचालित करते हैं।
मैं वर्णित रेक के बारे में अलग से, रंगीन उदाहरणों के साथ लिखूंगा, क्योंकि यह पहली बार "राष्ट्रीय अर्थव्यवस्था" की विभिन्न शाखाओं में दोहराया नहीं गया है।
डाटा प्रोसेसिंग की तकनीकी प्रक्रिया का विवरण (टेलीप्रोसेसिंग सहित) । गुफा की उम्र का एक दुस्साहसपूर्ण रूढ़िवाद, जब विशेष रूप से "कंप्यूटर ऑपरेटर्स" को मशीन पंच कार्ड्स खिलाने और एक लिफाफे में परिणाम के प्रिंटआउट को पैक करने के लिए निर्दिष्ट किया गया था। यह निर्देश उनके लिए है। 21 वीं सदी में इसमें क्या लिखना है - मैं आपको निश्चित रूप से नहीं बता सकता। अपने आप को बाहर निकालो। सबसे अच्छी बात यह है कि बस इस दस्तावेज़ के बारे में भूल जाओ।
सिस्टम-वाइड समाधान (OR) । मानक पीआर अनुभाग के 17 दस्तावेजों के लिए प्रदान करता है। सबसे पहले, ये प्रारंभिक डिजाइन के प्रारंभिक चरण के लगभग सभी दस्तावेज हैं। दूसरे, ये सभी प्रकार के अनुमान, गणना और स्वचालित कार्यों का एक संक्षिप्त विवरण हैं। यही है, लोगों के लिए जानकारी मुख्य आईटी उत्पादन से नहीं है, लेकिन सहायक कर्मचारियों के लिए - प्रबंधक, अनुमानक, खरीद विशेषज्ञ, अर्थशास्त्री, आदि।
और तीसरा, पीआर की संरचना में "तकनीकी परियोजना के लिए व्याख्यात्मक नोट" नामक एक मेगा-दस्तावेज़ शामिल है, जो कि कल्पना के रूप में, एक कार्यकारी सारांश है, और वास्तव में, कई डिजाइनर टीपी चरण के सभी उपयोगी सामग्री को इसमें शामिल करते हैं। इस तरह के एक कट्टरपंथी दृष्टिकोण को ग्राहक और ठेकेदार दोनों के लिए, लेकिन कुछ मामलों में पारस्परिक रूप से लाभकारी भी कहा जा सकता है।
GOST 34 का उपयोग करने के वेरिएंट
- . , , . , . «», 2 34.201-89 , . 50-34.698-90, . , , , . . . . , - .
- . . , . , , . , , , .
- , . . , «», — , . , , , . , ().
निष्कर्ष
यह लेख एसीएस के दस्तावेजीकरण के लिए हमारे GOSTs के बारे में था। GOST पुराने हैं, लेकिन, जैसा कि यह निकला, अभी भी घर में बहुत उपयोगी हैं। कुछ स्पष्ट रूढ़ियों के अलावा, प्रलेखन संरचना में पूर्णता और निरंतरता के गुण हैं, और मानक का पालन करने से कई डिज़ाइन जोखिमों को दूर किया जाता है, जिनके अस्तित्व के बारे में हम पहले नहीं जानते होंगे।मुझे उम्मीद है कि प्रस्तुत सामग्री आपके लिए उपयोगी थी, या कम से कम दिलचस्प थी। बाहरी ऊब के बावजूद, दस्तावेजीकरण एक महत्वपूर्ण और जिम्मेदार काम है, जिसमें सटीकता उतनी ही महत्वपूर्ण है जितनी अच्छी संहिता लिखते समय। अच्छे दस्तावेज, सहकर्मियों को लिखें! और अगले हफ्ते मैं एक पंक्ति में दो व्यावसायिक यात्राएं कर रहा हूं, इसलिए मैं नई सामग्रियों के प्रकाशन की गारंटी नहीं दे सकता (मेरे पास एक ज़ापाशनिक नहीं है, मैं अपने सिर से लिख रहा हूं)।