GOST 34 के अनुसार तकनीकी विशिष्टताओं का विकास सरल और आसान है

अक्सर आप यह राय सुनते हैं कि GOST 34 (TK) के अनुसार संदर्भ की शर्तों की तैयारी न केवल श्रमसाध्य है, बल्कि अत्यंत कष्टप्रद भी है, क्योंकि आपको सभी प्रकार के बकवास, पानी को लिखना होगा। लेकिन इसके बारे में सोचें: पूरे शोध संस्थान इस GOST के विकास में लगे हुए थे, यह राज्य स्तर पर एक परियोजना थी, सैकड़ों स्वचालन परियोजनाओं का अनुभव, जटिल परियोजनाओं को संक्षेप में प्रस्तुत किया गया था। क्या वे वास्तव में बकवास लिख सकते थे?

वास्तव में, एक सक्षम दृष्टिकोण के साथ, GOST बहुत ही न केवल तकनीकी विशिष्टताओं के विकास में मदद करता है, बल्कि एक पूरे के रूप में स्वचालन परियोजना के कार्यान्वयन के दौरान (और न केवल राज्य अनुबंधों में, बल्कि वाणिज्यिक विकास के लिए भी)। साक्षर लोगों ने इसे लिखा। लेकिन अपने मजदूरों के फलों का लाभ उठाने के लिए, किसी को न केवल टीके की अवधारणा को समझने की जरूरत है, बल्कि संपूर्ण रूप से GOST 34 को भी समझना होगा।

इस लेख में, हम GOST की सभी आवश्यकताओं को इंगित करके बिंदु का विश्लेषण करेंगे और GOST 34 के अनुसार टीके के विकास को एक बोझ नहीं, बल्कि परियोजना में एक बड़ी मदद बनाने का प्रयास करेंगे।

1. लेख किस बारे में है?

अक्सर आप यह राय सुनते हैं कि GOST 34 (TK) के अनुसार संदर्भ की शर्तों की तैयारी न केवल श्रमसाध्य है, बल्कि अत्यंत कष्टप्रद भी है, क्योंकि आपको सभी प्रकार के बकवास, पानी को लिखना होगा। लेकिन इसके बारे में सोचें: पूरे शोध संस्थान इस GOST के विकास में लगे हुए थे, यह राज्य स्तर पर एक परियोजना थी, सैकड़ों स्वचालन परियोजनाओं, जटिल परियोजनाओं का अनुभव सामान्य था। क्या वे वास्तव में बकवास लिख सकते थे?

वास्तव में, एक सक्षम दृष्टिकोण के साथ, GOST बहुत ही न केवल तकनीकी विशिष्टताओं के विकास में मदद करता है, बल्कि एक पूरे के रूप में स्वचालन परियोजना के कार्यान्वयन के दौरान (और न केवल राज्य अनुबंधों में, बल्कि वाणिज्यिक विकास के लिए भी)। साक्षर लोगों ने इसे लिखा। लेकिन अपने मजदूरों के फलों का लाभ उठाने के लिए, किसी को न केवल टीके की अवधारणा को समझने की जरूरत है, बल्कि संपूर्ण रूप से GOST 34 को भी समझना होगा।

वैसे, टीके पहला दस्तावेज नहीं है जिसे स्वचालन परियोजना के दौरान विकसित किया जा रहा है। यह स्पष्ट रूप से अनुच्छेद 1.5 में कहा गया है। GOST 34.602-89: "एनपीपी में टीके को प्रारंभिक डेटा के आधार पर विकसित किया गया है, जिसमें" एनपीपी निर्माण के अनुसंधान और औचित्य "चरण के अंतिम दस्तावेज शामिल हैं।" अधिक जानकारी के लिए, सूचना प्रणाली के विकास के दौरान मेरा लेख पूर्व-डिज़ाइन सर्वेक्षण देखें ।

ध्यान दें: इस लेख का उद्देश्य GOST को पुनरीक्षित करने के लिए नहीं है, और कुछ ITS प्रावधानों का विस्तार करने के लिए।

2. GOST 34 के अनुसार तकनीकी विशिष्टताओं की विशेषता

2.1। ToR को किस मानक से संकलित किया गया है?

GOST 34 के अनुसार TK के लिए मानक का पूरा नाम इस प्रकार है: GOST 34.602-89 "सूचना प्रौद्योगिकी (आईटी)। स्वचालित प्रणालियों के लिए मानकों का एक सेट। स्वचालित प्रणाली के निर्माण के लिए संदर्भ की शर्तें। "

मानक केवल 15 पृष्ठों (हां, काफी थोड़ा) पर मुद्रित होता है। भाषा रूसी है, वास्तव में रूसी है, और सिरिलिक वर्णमाला पर विदेशी नहीं है। यही है, यदि आप पहले से अपने सिर में ड्राइव नहीं करते हैं कि न तो GOSTs के ग्रंथों, न ही संघीय कानूनों, और न ही शोध प्रबंध केवल एक नश्वर को समझने के लिए सुलभ हैं, तो यह पढ़ना और घुसना काफी संभव है, हालांकि अक्सर पहली बार नहीं।

दरअसल, मानक कई अस्पष्ट शब्दों का उपयोग करता है। उदाहरण के लिए, भाषाई समर्थन से क्या मतलब है? उपयोग की गई अवधारणाओं को स्पष्ट करने के लिए, GOST 34.003-90 “सूचना प्रौद्योगिकी (आईटी) की ओर रुख करना चाहिए। स्वचालित प्रणालियों के लिए मानकों का एक सेट। स्वचालित प्रणाली। नियम और परिभाषाएँ। "

2.2। आपको संदर्भ की शर्तों के लिए GOST की आवश्यकता क्यों है?

संभवतः, जब आपको आपके लिए कुछ नए दस्तावेज़ की रचना करने की आवश्यकता होती है, तो आप इंटरनेट पर इस तरह के दस्तावेज़ के लिए एक टेम्पलेट की तलाश कर रहे हैं या सहकर्मियों से इसके लिए पूछें। इसलिए, दस्तावेजों या प्रक्रियाओं के लिए कोई भी मानक एक टेम्पलेट है। इसके अलावा, टेम्पलेट दस्तावेज़ के विकास को बहुत सरल करता है: संरचना और सामग्री आपके लिए पहले से ही सोची गई है, इसके अलावा, ऐसा टेम्पलेट ऐसे क्षणों को ध्यान में रखता है जो आपको याद नहीं होंगे।

2.3। परियोजना में संदर्भ की भूमिका क्या भूमिका निभाती है?

मानक आरडी 50-682-89 के पैराग्राफ 1.7 के अनुसार, "संदर्भ की शर्तें मुख्य दस्तावेज है जिसके अनुसार एयू का निर्माण और ग्राहक द्वारा स्वीकार किया जाता है।" और यह वास्तव में मुख्य दस्तावेज है। यह सब कुछ वर्णन करना चाहिए जो सिस्टम के विकास और कार्यान्वयन के लिए आवश्यक है।

टीओआर सिस्टम की समग्र उपस्थिति, काम की मात्रा (विकास की रूपरेखा), साथ ही साथ विकास और स्वीकृति प्रक्रिया को स्थापित करता है। सब कुछ TK से शुरू होता है और सब कुछ इसके साथ समाप्त होता है। यह दस्तावेज़ आपके ग्राहक को कार्य के महत्व और जटिलता को समझने के लिए आदर्श है और वह पैसे क्यों देता है।

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

औपचारिक रूप से टीके न बनाएं। यदि आप नहीं जानते कि क्या लिखना है, तो इसका मतलब है कि टीके को विकसित करना बहुत जल्दी है, आपको सिस्टम की समझ नहीं है, स्वचालित प्रक्रिया, स्वचालन वस्तु, अभी तक समझ में नहीं आई है। आपको सिस्टम की एक अवधारणा तैयार करनी चाहिए, हमने इस बारे में लेख की शुरुआत में बात की थी।

2.4। GOST 34.602-89 कितने पुराने हैं और क्या नए मानक हैं?

उतना पुराना नहीं। मैं किसी भी गैर-मुख्य चीजों को खोजने में लगभग असमर्थ था। और जो लोग दावा करते हैं कि GOST 34 अप्रचलित है, उनमें से कोई भी एक उदाहरण नहीं दे सकता है (शायद इसे पढ़ने की योग्यता नहीं है?) तथ्य यह है कि GOST स्वचालन परियोजना के लिए एक सामान्य दृष्टिकोण का वर्णन करता है, यह प्रोग्रामिंग के बारे में बात नहीं करता है। GOST 34 उस बारे में नहीं है।

खैर, अगर हम अन्य मानकों के साथ तुलना के बारे में बात करते हैं, तो तुलना करने के लिए कुछ खास नहीं है। GOST 34 स्वचालन परियोजना का इतना व्यापक दृष्टिकोण प्रदान करता है कि अन्य मानक outsole (मेरी राय में) के लिए उपयुक्त नहीं हैं। हां, वे सरल हैं (इसलिए, अधिक लोकप्रिय), लेकिन गहराई समान नहीं है। यहां उन मानकों की एक सूची दी गई है, जिनसे आपको स्वचालन परियोजना के लिए अपने मानकों को विकसित करते समय परिचित होना चाहिए:

• IEEE 830-1998 सॉफ्टवेयर आवश्यकताओं के लिए विशिष्टताओं को संकलित करने की पद्धति।
• GOST R ISO / IEC 12207-2010। सूचना प्रौद्योगिकी। सिस्टम और सॉफ्टवेयर इंजीनियरिंग। सॉफ्टवेयर जीवन चक्र प्रक्रियाओं।
• आईएसओ / आईईसी / IEEE 29148-2011। सिस्टम और सॉफ्टवेयर इंजीनियरिंग - जीवन चक्र प्रक्रिया - आवश्यकताएँ इंजीनियरिंग।
• GOST R 54869-2011। परियोजना प्रबंधन। परियोजना प्रबंधन की आवश्यकताएं।
• अच्छी तरह से और राज्य मानक विनिर्देशों 34 श्रृंखला।

3. GOST 34 के अनुसार तकनीकी विशिष्टताओं की तैयारी के लिए सामान्य सिद्धांत

3.1। किस विशेषज्ञ को GOST 34 के अनुसार संदर्भ की शर्तें तैयार करनी चाहिए?

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

संदर्भ की शर्तों को एक व्यापार विश्लेषक द्वारा बनाया जाना चाहिए, क्योंकि वह ग्राहक और विकास टीम के बीच एक "अनुवादक" है। एक व्यापार विश्लेषक का कार्य यह समझना है कि ग्राहक को क्या चाहिए और इसे टीम के लिए स्पष्ट तरीके से व्यक्त करना चाहिए। और इसे तकनीकी विशिष्टताओं के रूप में व्यक्त करते हैं। इसके अलावा, एक व्यापार विश्लेषक को न केवल ग्राहक और उसके कर्मचारियों को सुनने के लिए आवश्यक है, बल्कि यह पता लगाने के लिए कि उन्होंने क्या नहीं कहा (और यह आमतौर पर 50% से अधिक है)। इसलिए, विश्लेषक को स्वचालित होने वाली प्रक्रियाओं का अच्छा ज्ञान होना चाहिए और, उनके ज्ञान के कारण, सर्वेक्षण के परिणामों पर बने अंतराल में भरें।

3.2। संदर्भ की शर्तें किस पक्ष की होनी चाहिए?

मूलतः, संदर्भ की शर्तें ठेकेदार द्वारा संकलित की जाती हैं? क्यों?

केवल इसलिए नहीं कि इसे परिशिष्ट 1 से GOST 34-602-89 में अनुशंसित किया गया है। वास्तव में, ग्राहक, एक नियम के रूप में, उपयुक्त विशेषज्ञ नहीं है। लेकिन TK आवश्यक रूप से विकसित और ग्राहक द्वारा सहमत है। और यहां यह सुनिश्चित करना आवश्यक है कि समझौता औपचारिक नहीं है। मैं हमेशा जोर देकर कहता हूं कि हम ग्राहक के साथ मिलकर प्रत्येक वस्तु का विस्तार से विश्लेषण करें। आपका लक्ष्य ग्राहक को परियोजना में शामिल करना है। अन्यथा, वह सिस्टम की अपनी अपेक्षाओं को नहीं बनाएगा, जिसका अर्थ है कि, सबसे पहले, वह किसी भी परिणाम से असंतुष्ट होगा, और दूसरी बात, वह आवश्यक संगठनात्मक उपायों को पूरा करने में सक्षम नहीं होगा।

3.3। आप GOST 34 से कितनी दूर जा सकते हैं?

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

वास्तव में, ऐसा नहीं है। कोई भी प्रक्रिया मानक (अर्थात, सॉसेज के लिए नहीं, बल्कि कुछ गतिविधि के लिए एक मानक) केवल सामान्य संकेत देता है, रूपरेखा। यह आपके लिए पीढ़ियों के अनुभव पर पारित करने के लिए, और झंडे के पीछे आपको नहीं चलाने के लिए कुछ महत्वपूर्ण भूल न करने में मदद करने के लिए बनाया गया था।

विश्वास नहीं होता? फिर GOST 34.602-89 का क्लॉज 2.2 पढ़ें (वैसे, हाइफ़न के बाद की संख्या मानक या उसके संस्करण के प्रकाशन का वर्ष है): "प्रकार, उद्देश्य, स्वचालन वस्तु की विशिष्ट विशेषताओं और सिस्टम के कामकाज की स्थितियों के आधार पर, यह अनुप्रयोगों के रूप में टीके के वर्गों को खींचने की अनुमति देता है, अतिरिक्त परिचय देता है। टीके का बहिष्करण या विलय करें। " इसके अलावा पैराग्राफ 1.2 में। RD 34.698-90 कहता है: “दस्तावेजों की सामग्री सभी प्रकार के AS के लिए आम है और यदि आवश्यक हो, तो बनाए गए AS की विशेषताओं के आधार पर दस्तावेजों के डेवलपर द्वारा पूरक किया जा सकता है। इसे अतिरिक्त खंडों और सूचनाओं को दस्तावेजों में शामिल करने, अनुभागों को संयोजित करने और बाहर करने की अनुमति है। "

सामान्य तौर पर, यदि आप केवल सामान्य वाक्यांशों का हवाला दे सकते हैं, तो सब कुछ अच्छा करने के लिए, कुछ भी बुरा करने के लिए, कुछ भी नहीं लिखें। अन्यथा, दस्तावेज़ को पढ़ने वाले विशेषज्ञ, ऐसे मार्ग से मिले हैं, दस्तावेज़ को गंभीरता से लेना बंद कर देगा, और महत्वपूर्ण बिंदुओं को याद किया जाएगा। किसी दस्तावेज़ को यातना पढ़ना मत बनाओ!

3.4। GOST 34 के अनुसार TK इतनी आवश्यकताओं का वर्णन क्यों करता है जो सीधे सिस्टम के कार्यों से संबंधित नहीं हैं?

वास्तव में, 30 पृष्ठों के टीओआर में, केवल 7-10 पृष्ठ कार्यों के लिए समर्पित हो सकते हैं। इसका एक स्पष्टीकरण है। तथ्य यह है कि GOST 34 के डेवलपर्स ने स्वचालन परियोजना को पूरी तरह से अलग तरीके से देखा था, जो हमने किया था। और वे अधिक सही ढंग से, अधिक व्यापक रूप से दिखे।

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

दूसरे , GOST 34 के कंपाइलरों ने सिस्टम को मुख्य रूप से लोगों के रूप में देखा, और फिर एक हार्डवेयर-सॉफ्टवेयर कॉम्प्लेक्स के रूप में। यह कैसे GOST 34.003-90 एक स्वचालित प्रणाली को परिभाषित करता है: "एक प्रणाली जिसमें कर्मियों से युक्त है और अपनी गतिविधियों के लिए स्वचालन उपकरण का एक सेट है जो स्थापित कार्यों को करने के लिए सूचना प्रौद्योगिकी को लागू करता है।" इस प्रकार, एक सूचना प्रणाली एक प्रशिक्षित कर्मियों, सॉफ्टवेयर और हार्डवेयर परिसर है, सभी एक साथ। वास्तव में, एकाउंटेंट से कंप्यूटर ले लो, वे मुश्किल हैं, लेकिन कागज रजिस्ट्रियों के साथ, अपना काम करने में सक्षम होंगे। लेकिन 1 सी एक एकाउंटेंट के बिना स्वतंत्र रूप से काम नहीं करेगा। इसलिए संगठनात्मक उपायों पर टीके के कई खंड। जैसा कि वे कहते हैं, एक आईटी प्रणाली 20% आईटी है, बाकी सभी संगठनात्मक उपाय हैं। अर्थात्, TK एक दस्तावेज है जो सिस्टम के कार्यान्वयन के लिए आवश्यक सभी चीजों को मंत्र देता है, ए से जेड तक।

तीसरा , GOST 34.602-89 के नाम पर ध्यान दें: "स्वचालित प्रणाली के निर्माण के लिए संदर्भ की शर्तें।" टीके सिस्टम के लिए नहीं है, बल्कि सिस्टम के निर्माण के लिए है। अंतर क्या है? अंतर यह है कि टीओआर न केवल सिस्टम के लिए आवश्यकताओं को स्थापित करता है, बल्कि इसके निर्माण की प्रक्रिया को भी नियंत्रित करता है, अर्थात, दस्तावेज़ में सभी संगठनात्मक उपायों के लिए आवश्यकताएं हैं, जिसके कार्यान्वयन के लिए परिणाम प्राप्त करना आवश्यक है। दरअसल, एक स्वचालन परियोजना के कार्यान्वयन के दौरान, कई प्रक्रियाओं का पुनर्गठन करना, कर्मियों को प्रशिक्षित करना और हार्डवेयर तैयार करना अक्सर आवश्यक होता है।

चौथा , टीओआर एक दस्तावेज है जिसके द्वारा आप टिक कर सकते हैं: क्या हमने इस आवश्यकता को ध्यान में रखा है या नहीं। हो सकता है कि आप 10 टिक्कियों को अपने आप साफ कर दें, क्योंकि ये मानक समाधान होंगे। लेकिन चेकमार्क नंबर 11 एक बहुत बड़ी समस्या को प्रकट करेगा, और यदि आप अभी इस समस्या को छोड़ देते हैं, तो यह कार्यान्वयन प्रक्रिया में कहीं न कहीं पॉप अप हो जाएगा, जब सभी समय सीमाएं और बजट पहले ही निर्धारित हो चुके होंगे।

पांचवां , जैसा कि हमने ऊपर कहा, अनावश्यक उपखंडों को बाहर रखा जा सकता है, इसकी अनुमति है। उदाहरण के लिए, यदि आप यह सुनिश्चित करने के लिए जानते हैं कि आपके डिजाइनों में कुछ भी पेटेंट नहीं किया जा सकता है, तो पेटेंट शुद्धता आवश्यकताओं को क्यों लाया जाए? यह तब नहीं है जब पानी के बिना पानी न हो और न ही कोई स्यूड हो।

3.5। अलग-अलग वर्ग एक ही बात क्यों कहते हैं?

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

लेकिन छोटी प्रणालियों के लिए, केवल एक या दो प्रशासक और मध्यस्थों की एक जोड़ी की आवश्यकता होती है। इस मामले में, हमारे पास दो संपूर्ण वर्गों में वर्णन करने के लिए कुछ भी नहीं है। फिर कुछ वर्गों को छोड़ दें, और दूसरे में, आवश्यकताओं का पूरा विवरण दें।

3.6। क्या मुझे एक गुणवत्ता तरीके से टीके जारी करने की आवश्यकता है?

यद्यपि टीके के डिजाइन की आवश्यकताएं GOST 34.602-89 के पैरा 3 में दी गई हैं, आइए इस पहलू के बारे में कुछ शब्द बताते हैं।

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

टीके जैसे बड़े दस्तावेजों के निष्पादन के लिए यहां कुछ सुझाव दिए गए हैं।

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

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

चौथा, प्रत्येक व्यक्तिगत आवश्यकता को एक अलग क्रमांकित पैराग्राफ में निर्धारित किया जाना चाहिए। यदि एक टुकड़े में 2-3 आवश्यकताएं हैं, तो केवल पहले पढ़ा जाता है, और हमारा मस्तिष्क बाकी को छोड़ देता है। टीके एक दस्तावेज है जिसमें, प्रत्येक पैराग्राफ के सामने, आप जांच सकते हैं कि आवश्यकता पूरी हुई या नहीं।

पांचवां , लिंक के प्लेसमेंट पर कंजूसी न करें। कभी-कभी आप एक पैराग्राफ पढ़ते हैं जहां कुछ फ़ंक्शन या आवश्यकता का उल्लेख किया जाता है, और आप समझ नहीं पाते हैं, यह एक ही दस्तावेज़ या दूसरे से है। यदि इसमें से है, तो किस सेक्शन में है। इसलिए, अन्य वर्गों को संदर्भित करने का प्रयास करें यदि वे वर्तमान पाठ में उल्लिखित हैं। स्वाभाविक रूप से, लिंक स्वचालित होना चाहिए।

ध्यान दें कि, सख्त नियमों के अनुसार, काम का विवरण एक फ्रेम के बिना तैयार किया गया है (यह पैराग्राफ 3 में कहा गया है), लेकिन एक फ्रेम के साथ बाकी दस्तावेज। यह GOST 24.301-80 में स्थापित किया गया है "एसीएस के लिए तकनीकी दस्तावेज की प्रणाली। पाठ दस्तावेजों के कार्यान्वयन के लिए सामान्य आवश्यकताएं (जैसा कि संशोधित नंबर 1, 2)। ” यह मानक टीके को छोड़कर सभी दस्तावेजों के निष्पादन के नियमों को स्थापित करता है और पूर्व-डिज़ाइन चरणों में बनाए गए दस्तावेज़। हालांकि मुझे व्यक्तिगत रूप से किसी भी दस्तावेज में फ्रेम पसंद नहीं है।

4. धारा 1. "सामान्य जानकारी" / पी। 2.3 GOST 34.602-89 /

इस खंड में प्रस्तुत अधिकांश जानकारी को टिप्पणी की आवश्यकता नहीं है, इसलिए हम केवल कुछ उपखंडों पर ध्यान केंद्रित करेंगे।

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

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

5. खंड 2. "उद्देश्य और प्रणाली बनाने (विकसित करने) के लक्ष्य" / पी। 2.4 GOST 34.602-89 /

यहां हमें सिस्टम बनाने के उद्देश्य और उद्देश्य के बीच के अंतर को समझने की आवश्यकता है। बहुत बार, ये अवधारणाएं भ्रमित हैं। उदाहरण के लिए, वे लिखते हैं कि सिस्टम का उद्देश्य आपके व्यक्तिगत खाते का स्वचालन है, और लक्ष्य एक व्यक्तिगत खाता बनाना है। तेल ही तेल है। कुछ मामलों में, ये अवधारणाएं वास्तव में मेल खाती हैं, फिर केवल नियुक्ति लिखें।

उद्देश्य के साथ, सब कुछ स्पष्ट है: हम स्वचालित गतिविधि के प्रकार (प्रकार) देते हैं। उदाहरण के लिए, यदि हम उत्पादन लेखांकन के लिए एक प्रणाली बनाते हैं, तो यह स्वचालित प्रकार के लेखांकन, स्वचालित संचालन, साथ ही उन वस्तुओं का भी हवाला देता है, जिनके स्वचालन की आवश्यकता है।

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

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

GOST यह भी कहता है कि लक्ष्य की उपलब्धि का आकलन करने के लिए मापदंड प्रदान करना आवश्यक है, अर्थात्, विशिष्ट संकेतक। उदाहरण के लिए, हमारे पास प्रति दिन कुल 20 ऑर्डर एकत्र करने वाले 3 लोग हैं। और सिस्टम के लागू होने के बाद, हम चाहते हैं कि हर कोई 20 ऑर्डर इकट्ठा करे, यानी तीन गुना ज्यादा। यदि ऐसे संकेतक वहां ज्ञात हैं, तो हम उन्हें इस पैराग्राफ में प्रस्तुत करते हैं।

6. खंड 3. "स्वचालन वस्तु के लक्षण" / पी। 2.5 GOST 34.602-89 /

एक बहुत ही महत्वपूर्ण, और अक्सर औपचारिक रूप से वर्णित अनुभाग। हालांकि, मेरी राय में, यह TK का सबसे महत्वपूर्ण खंड है, इसके बिना हम बस यह नहीं समझते हैं कि सिस्टम किस बारे में बनाया जा रहा है।

चलो पहले परिभाषित करते हैं कि "स्वचालन वस्तु" क्या है। यदि हम एक गोदाम या एक संयंत्र, एक लेखा विभाग को स्वचालित करते हैं, तो सब कुछ स्पष्ट है। और अगर, उदाहरण के लिए, हम एक नया सामाजिक नेटवर्क बनाते हैं, तो ऑब्जेक्ट, जैसा कि यह था, मौजूद नहीं है। लेकिन वास्तव में, एक वस्तु का मतलब स्वचालित प्रक्रियाओं से अधिक है। और यहां तक ​​कि एक गोदाम के मामले में, हम स्वयं गोदाम को स्वचालित नहीं करते हैं (बक्से के भंडारण को स्वचालित कैसे किया जा सकता है?), लेकिन गोदाम प्रक्रियाएं।

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

इस अनुभाग में शामिल होना चाहिए:

1. ग्राहक का विवरण: ग्राहक की गतिविधियाँ, शाखाओं की संख्या, कर्मचारी। बेशक, आपको उस हिस्से में ग्राहक को चिह्नित करने की आवश्यकता है जो सीधे सिस्टम के निर्माण से संबंधित है।
2. सिस्टम उपयोगकर्ताओं के बारे में जानकारी: उपयोगकर्ताओं के प्रकार, सिस्टम विभिन्न उपयोगकर्ताओं के लिए क्या भूमिका निभाता है।
3. स्वचालित वस्तुओं का विवरण। उदाहरण के लिए, यदि हम एक गोदाम को स्वचालित करते हैं, तो हमें यह बताना होगा कि इसमें कितना क्षेत्र है, कितने रास्ते हैं, कितने रास्ते हैं, कितने रास्ते हैं, क्या रैक हैं, क्या अलग विधानसभा क्षेत्र है, कितने लोग काम करते हैं और उनकी क्या जिम्मेदारियाँ हैं। तब हम समझेंगे कि हम विशेष रूप से स्वचालित कर रहे हैं कि वेयरहाउस प्रक्रिया क्या दिखना चाहिए और किस उपकरण का उपयोग किया जा रहा है।
4. स्वचालित प्रक्रियाओं का विवरण। बेशक, टीके में विस्तार से प्रक्रियाओं का वर्णन करना आवश्यक नहीं है। लेकिन आम परिदृश्यों की आवश्यकता है। तभी यह हमारे लिए स्पष्ट हो जाता है कि क्या कार्य उपलब्ध होने चाहिए।
5. दस्तावेजों की एक सूची जो स्वचालन वस्तु का विस्तृत विवरण प्रदान करती है।

मेरे पास ऐसे मामले हैं जब इस खंड का वर्णन टीके के आधे से अधिक विकास में हुआ, क्योंकि इसमें अलग-अलग जानकारी एकत्र करने, विश्लेषण करने और सावधानीपूर्वक वर्णन करने में लंबा समय लगता है।

7. धारा 4 "सिस्टम आवश्यकताएँ"

TK में GOST 34 के अनुसार एक विशाल भाग है: खंड 4 "सिस्टम आवश्यकताएँ"। इसके तीन उपखंड हैं:

• एक पूरे के रूप में सिस्टम के लिए आवश्यकताएँ।
• सिस्टम द्वारा किए गए कार्यों (कार्यों) के लिए आवश्यकताएँ।
• संपार्श्विक के प्रकार के लिए आवश्यकताएँ।

हम इन उपखंडों पर अलग से विचार करेंगे।

7.1। ग्राहकी ४.१। "पूरे सिस्टम के लिए आवश्यकताएँ" / पी। 2.6.1 GOST 34.602-89 /

उप-धारा 4.1 "सिस्टम के लिए आवश्यकताएं" के रूप में, तथाकथित गैर-कार्यात्मक, सामान्य, आवश्यकताओं का वर्णन किया गया है जो सिस्टम को विभिन्न कोणों से बनाया जा रहा है।

वैसे, जैसा कि हमने पहले ही उल्लेख किया है, उपधाराओं को जोड़ा और छोड़ा जा सकता है। इसलिए, यहां दी गई संख्या अनुमानित है, लेख के भीतर अभिविन्यास के लिए कार्य करती है।

7.1.1। खंड 4.1.1। "सिस्टम की संरचना और कामकाज के लिए आवश्यकताएँ" / पी। 2.6.1.1 GOST 34.602-89 /

यह आइटम काफी व्यापक है, इसे सिस्टम की वास्तुकला का एक सामान्य विचार देना चाहिए। हम इन आवश्यकताओं का अधिक विस्तार से विश्लेषण करेंगे।

1. उप-प्रणालियों की सूची, उनका उद्देश्य और मुख्य विशेषताएं, पदानुक्रम स्तर की संख्या और सिस्टम के केंद्रीकरण की डिग्री के लिए आवश्यकताएं।

इस अनुच्छेद में, मैं आमतौर पर उद्धृत करता हूं:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

यदि आप एक माइक्रो-आर्किटेक्चर की योजना बना रहे हैं, तो यह सेवाओं की कार्यक्षमता को सूचीबद्ध करने और वर्णन करने के लिए समझ में आता है।

स्पष्टता के लिए, सिस्टम के एक संरचनात्मक आरेख को इसके भागों और संबंधित प्रणालियों के पदनाम के साथ संलग्न करना वांछनीय है, जैसा कि नीचे दिए गए उदाहरणों में दिखाया गया है।



... या तो:



2. सिस्टम घटकों के बीच सूचना विनिमय के लिए संचार विधियों और साधनों की आवश्यकता।

3. संबंधित सिस्टम के साथ बनाई गई प्रणाली के संबंधों की विशेषताओं के लिए आवश्यकताएँ, इसकी संगतता के लिए आवश्यकताएं, जिसमें सूचनाओं का आदान-प्रदान करने के निर्देश (स्वचालित रूप से, दस्तावेज़ भेजना, फोन आदि) शामिल हैं।

आधुनिक परिस्थितियों में, HTTP (S) प्रोटोकॉल का उपयोग करके अधिकांश इंटरैक्शन किए जाते हैं। ऐसा लगता है, इसके अलावा, लिखने के लिए कुछ भी नहीं है। हालांकि, ये आइटम इतने बड़े हो सकते हैं कि वे आवेदन के लिए प्रस्तुत किए जाते हैं। उन्हें निम्नलिखित जानकारी प्रदान करनी चाहिए:

• संचरित जानकारी की एक सूची, कम से कम एक सामान्य विवरण, आमतौर पर यह समझने के लिए कि हम एक विशिष्ट प्रणाली के साथ क्यों एकीकृत कर रहे हैं;
• प्रोटोकॉल विवरण (या विवरण लिंक), विशेष रूप से डिवाइस के लगाव के मामले में;
• स्थानीय नेटवर्क संरचना;
• आवश्यक डेटा दर;
• मोबाइल इंटरनेट या वाईफाई का उपयोग;
• गैर-स्वचालित डेटा ट्रांसमिशन विधियों का विवरण।

4. सिस्टम के ऑपरेटिंग मोड के लिए आवश्यकताएँ।
ऑपरेशन के मोड में कई वर्गीकरण हो सकते हैं:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• ऐप विजिबिलिटी: डायलॉग या बैकग्राउंड
• सिस्टम पर संभावित प्रभाव पर: नियमित, प्रशिक्षण, परीक्षण मोड।

5. प्रणाली के निदान के लिए आवश्यकताएँ।

Microservice (रिक्ति) आर्किटेक्चर पर आधारित सिस्टम के लिए निरंतर या आवधिक निदान की आवश्यकताएं होनी चाहिए, सिस्टम में उपकरण शामिल हैं: सेंसर, नियंत्रण प्रणाली, टर्मिनल आदि। बेशक, यदि केवल सॉफ्टवेयर विकसित किया गया है जो एकल सर्वर पर चलता है, तो ये आवश्यकताएं बहुत कम हैं: आपको पता चलेगा कि क्या कुछ काम करना बंद कर देता है।

6. प्रणाली के विकास, आधुनिकीकरण की संभावनाएँ।

ऐसा लगता है, प्रणाली के विकास के लिए संभावनाएं क्या हैं "सिस्टम की संरचना और कामकाज के लिए आवश्यकताएँ"? लेकिन कल्पना कीजिए, अब आप 100 लोगों के लिए एक अल्फा संस्करण बना रहे हैं, और एक साल में आप दुनिया के विभिन्न हिस्सों में एक साथ काम करने वाले उपयोगकर्ताओं को एक मिलियन से अधिक प्राप्त करना चाहते हैं। फिर, सृजन के स्तर पर, आपको तुरंत एक क्लस्टर वास्तुकला के लिए प्रदान करने की आवश्यकता है।

या अब आप एक संगठन से काम कर रहे हैं, और छह महीनों में उनमें से कई होंगे, जिसका अर्थ है कि अग्रिम में विस्तार की संभावना को दूर करना आवश्यक है।

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

7.1.2। खंड 4.1.2। "कर्मियों की संख्या और योग्यता के लिए आवश्यकताएँ" / पी। 2.6.1.2 GOST 34.602-89 /

जैसा कि हमने पहले उल्लेख किया है, किसी भी स्वचालित प्रणाली में "कर्मियों और इसकी गतिविधियों के लिए स्वचालन उपकरण का एक सेट" होता है। इसलिए, कर्मियों की आवश्यकताओं और उनकी योग्यता टीओआर में इंगित की गई है।

यदि आप एक विशिष्ट उत्पादन लाइन को स्वचालित करते हैं, तो आप कर्मचारियों की संख्या जानते हैं। लेकिन कई मामलों में, यह प्रदर्शन किए गए कार्य की मात्रा पर निर्भर करता है। इसलिए, पदों, कार्य अनुसूची, गतिविधियों का वर्णन (एक्सेस अधिकारों को निर्दिष्ट करने के लिए) और अनुमानित योग्यताएं इंगित करें। कम से कम, आपको एक सिस्टम प्रशासक और ऑपरेटर की आवश्यकता है, जो अक्सर एक मध्यस्थ होता है। यह संभव है कि आपको कई प्रकार के ऑपरेटरों के लिए विभिन्न स्तरों तक पहुंच प्रदान करनी होगी।

यह स्पष्ट है कि कर्मियों के लिए आवश्यकताओं को अक्सर ग्राहक द्वारा निर्धारित किया जाता है, फिर उन्हें क्यों लाएं? लेकिन, सबसे पहले, हमने पहले ही कहा है कि तकनीकी विनिर्देश दोनों पक्षों के लिए तैयार किए गए हैं, और दूसरी बात, ठेकेदार की रक्षा की जाएगी: कर्मचारियों के चयन की शर्त पूरी नहीं हुई है, तो सिस्टम लागू नहीं होने पर ग्राहक क्या चाहता है?

7.1.3। खंड 4.1.3। "प्रदर्शन संकेतक के लिए आवश्यकताएँ" / पी। 2.6.1.3 GOST 34.602-89 /

इस उपधारा में, यह अक्सर लिखा जाता है कि आपको क्या पसंद है, चूंकि GOST पाठ में संभावित संकेतकों की सूची गायब है, और उन्हें खुले स्रोतों में ढूंढना लगभग असंभव है। कृपया ध्यान दें कि GOST में दी गई "अनुकूलन क्षमता की डिग्री", "आधुनिकीकरण की सीमाएं" और "संभाव्यता-समय की विशेषताएँ", सबसे पहले, ACS (स्वचालित नियंत्रण प्रणाली) के लिए इंगित की जाती हैं और, दूसरी बात, उन्हें मापना मुश्किल है। इस प्रकार, ये विशेषताएँ हमेशा उपयुक्त नहीं होती हैं।

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

गंतव्य संकेतक में शामिल हैं:

• सिस्टम में एक साथ काम करने वाले उपयोगकर्ताओं की संख्या;
• सर्वर पर एक साथ निष्पादित अनुरोधों की संख्या;
• लेनदेन की प्रति यूनिट समय में लेनदेन (दर्ज) की संख्या;
• संसाधित डेटा की एक अलग राशि के लिए एक बार के अनुरोधों और काम करने वाले उपयोगकर्ताओं की एक अलग संख्या के लिए प्रतिक्रिया समय (विशेषकर जब रिपोर्ट की खोज और एकत्रीकरण);
• संग्रहीत डेटा की मात्रा (विशेष रूप से, चित्र और वीडियो);
• अधिकतम लोड तक पहुंचने पर अतिरिक्त कंप्यूटिंग शक्ति के लिए कनेक्शन का समय;
• संग्रहित डेटा की मात्रा में उल्लेखनीय वृद्धि के साथ अतिरिक्त क्षमताओं का कनेक्शन समय।

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

7.1.4। खंड 4.1.4। "विश्वसनीयता के लिए आवश्यकताएँ" / पी। 2.6.1.4 GOST 34.602-89 /

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

बुनियादी अवधारणा जो स्वचालित प्रणालियों पर लागू की जा सकती है वह उपलब्धता कारक है: 99%, 99.9%, 99.99%। "निन्स" की प्रत्येक संख्या कुछ उपायों द्वारा प्रदान की जाती है।

इन आवश्यकताओं को क्या तकनीकी समाधान प्रभावित कर सकते हैं? यह आरक्षित क्षमताओं की संख्या (वे अलग-अलग हैं), और जमीन पर तकनीकी कर्मचारियों की उपलब्धता, और न केवल निर्बाध बिजली की आपूर्ति का उपयोग करते हैं, बल्कि डीजल जनरेटर भी हैं, साथ ही दो स्वतंत्र स्रोतों से कनेक्शन (विश्वसनीयता श्रेणी I या II के अनुसार बिजली ग्रिड का कनेक्शन)।

7.1.5। खंड 4.1.5। "सुरक्षा आवश्यकताएँ" / पी। 2.6.1.5 GOST 34.602-89 /

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

7.1.6। खंड 4.1.6। "एर्गोनॉमिक्स और तकनीकी सौंदर्यशास्त्र के लिए आवश्यकताएँ" / पी। 2.6.1.6 GOST 34.602-89 /

हम GOST की आवश्यकताओं को देते हैं: "एर्गोनॉमिक्स और तकनीकी सौंदर्यशास्त्र के लिए आवश्यकताओं में एसी संकेतक शामिल हैं जो मशीन के साथ मानव बातचीत की आवश्यक गुणवत्ता और कर्मचारियों की कामकाजी परिस्थितियों के आराम को निर्दिष्ट करते हैं।"

आमतौर पर इस पैराग्राफ में लिखा है कि सिस्टम में एक सुविधाजनक और सुंदर इंटरफ़ेस होना चाहिए। लेकिन सुविधा और सुंदरता कैसे मापें? इसलिए, हम या तो इस आवश्यकता को छोड़ देते हैं, या हम कहते हैं कि इंटरफ़ेस बाद में विकसित एक डिजाइन परियोजना के अनुरूप होगा, या हम मानक प्रदान करते हैं, उदाहरण के लिए, मोबाइल एप्लिकेशन विकसित करने के लिए तथाकथित "दिशानिर्देश": Android के लिए सामग्री डिज़ाइन और iOS के लिए मानव इंटरफ़ेस दिशानिर्देश ।

आप कुछ कार्यों को लागू करते समय अधिकतम संख्या में परिवर्तन (क्लिक) कर सकते हैं जो हमारे लिए विशेष रूप से महत्वपूर्ण हैं, डेटा खोज की औसत गति आदि।

7.1.7। खंड 4.1.7। "मोबाइल वक्ताओं के लिए परिवहन की आवश्यकताएं" / पी। 2.6.1.7 GOST 34.602-89 /

कुछ अप्रचलित आवश्यकता कहें। अब ट्रकों पर सर्वर, बड़े कंप्यूटर की तरह, पहले नहीं चलते हैं। फिर भी, कल्पना करें कि आपके पास किसी प्रकार का सुपरप्रोटेक्शन है, डीएमजेड के पीछे एक आंतरिक सर्किट और ... एक लैपटॉप के माध्यम से दूरस्थ कार्य की आवश्यकता है। हां, वीपीएन किसी भी समय कॉन्फ़िगर किया गया है, लेकिन यह बेहतर है यदि यह प्रशासन गाइड में परिलक्षित होता है, और संभावना स्वयं नेटवर्क कॉन्फ़िगरेशन द्वारा प्रदान की जाती है।

7.1.8। खंड 4.1.8। "ऑपरेशन, रखरखाव, मरम्मत और भंडारण के लिए आवश्यकताएँ" / पी। 2.6.1.8 GOST 34.602-89 /

ये आवश्यकताएं तकनीकी साधनों (सर्वर, फायरवॉल, स्विच, वर्कस्टेशन आदि) के एक परिसर के रखरखाव से संबंधित हैं। यदि उपकरण को किसी विशेष रखरखाव की आवश्यकता होती है, तो इस अनुभाग में इसका वर्णन करना आवश्यक है। उदाहरण के लिए, आपके पास एक विशेष उपकरण है जिसे महीने में एक बार कैलिब्रेट करने की आवश्यकता होती है।

7.1.9। खंड 4.1.9। "अनधिकृत पहुंच से सूचना के संरक्षण के लिए आवश्यकताएँ" / पी। 2.6.1.9 GOST 34.602-89 /

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

यह ध्यान रखना महत्वपूर्ण है कि इस उपधारा में न केवल उन उपायों को दिया जाता है जिन्हें सिस्टम के विकास के दौरान लागू किया जाना चाहिए, बल्कि इसका संचालन भी।

इसलिए, वित्तीय प्रणालियों के लिए, आपको "भुगतान कार्ड उद्योग डेटा सुरक्षा मानक" (PCI DSS) का उपयोग करना चाहिए। उन प्रणालियों के लिए जिनमें व्यक्तिगत डेटा संग्रहीत किया जाता है, - रूसी संघ की सरकार की डिक्री दिनांक 01.11.2012 नंबर 1119 "व्यक्तिगत डेटा सूचना प्रणालियों में उनके प्रसंस्करण के दौरान व्यक्तिगत डेटा की सुरक्षा के लिए आवश्यकताओं के अनुमोदन पर"। आपके विषय क्षेत्र में अन्य मानक हो सकते हैं।

सामान्य तौर पर, सुरक्षात्मक उपकरणों को निम्न प्रकारों में विभाजित किया जा सकता है:

1. निर्मित सॉफ्टवेयर उत्पाद द्वारा प्रदान किए गए साधन।
2. सिस्टम प्रशासक द्वारा प्रदान किए गए उपाय।
3. शारीरिक सुरक्षा के उपाय।
4. सामान्य संगठनात्मक उपाय।
5. सॉफ्टवेयर विकास प्रक्रिया के दौरान किए गए उपाय।

1. बनाए गए सॉफ्टवेयर उत्पाद द्वारा प्रदान किए गए सुरक्षा उपाय:

• उपयोगकर्ताओं के लिए पासवर्ड की आवश्यकता, विशेष रूप से व्यवस्थापक भूमिका वाले उपयोगकर्ताओं के लिए।
• भूमिका-आधारित पहुंच मॉडल लागू करना।
• आलोचनात्मक संचालन करने के लिए इलेक्ट्रॉनिक हस्ताक्षर कुंजी का उपयोग करने की आवश्यकता।
• DMZ में बाहरी सिस्टम के साथ बातचीत के लिए जिम्मेदार सॉफ्टवेयर घटकों को हटाना।
• घटनाओं और उपयोगकर्ता कार्यों का पंजीकरण प्रदान करना।

2. सिस्टम प्रशासक द्वारा प्रदान किए गए उपाय:

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

3. शारीरिक सुरक्षा उपाय:

• महत्वपूर्ण कमरों तक सीमित पहुंच।
• सार्वजनिक स्थानों पर नेटवर्क कनेक्टर्स को डिस्कनेक्ट करें।
• महत्वपूर्ण परिसरों के लिए सीसीटीवी कैमरों की स्थापना।

4. सामान्य संगठनात्मक उपाय:

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

5. सॉफ्टवेयर विकास प्रक्रिया के दौरान किए गए उपाय:

• जिम्मेदार व्यक्ति कार्यक्रम कोड में बदलाव करने के लिए नियंत्रण करते हैं, सूचना सुरक्षा नियमों के अनुपालन के लिए कोड की जांच करते हैं (बफर ओवरफ्लो नियंत्रण, सही त्रुटि से निपटने, क्रॉसिंग स्क्रिप्टिंग के लिए जांच, पहुंच तंत्र त्रुटियों, आदि)
• मजबूत क्रिप्टोग्राफी का उपयोग।
• सार्वजनिक वेब अनुप्रयोगों के लिए सुरक्षा नियमों का अनुप्रयोग।
• प्रत्येक परिवर्तन के लिए रद्दीकरण प्रक्रिया विकसित करें।
• परिवर्तनों का दस्तावेजीकरण।

7.1.10। खंड 4.1.10। "दुर्घटनाओं के मामले में सूचना की सुरक्षा के लिए आवश्यकताएँ" / पी। 2.6.1.10 GOST 34.602-89 /

यह खंड संभावित दुर्घटनाओं और विफलताओं की एक सूची प्रदान करता है जिसमें सूचना की सुरक्षा सुनिश्चित की जानी चाहिए। इस तरह की घटनाओं में शामिल हो सकते हैं:

• पोषण की हानि;
• सर्वर की विफलता;
• स्टोरेज डिवाइस की विफलता (हार्ड डिस्क)।

7.1.11। खंड 4.1.11। "बाहरी प्रभावों के प्रभाव से सुरक्षा के लिए आवश्यकताएं" / पी। 2.6.1.11 GOST 34.602-89 /

यह खंड एक ठंडे गोदाम में सर्वर, वर्कस्टेशन और अन्य उपकरणों के मामले में उपयोगी होगा, या इसके विपरीत, औद्योगिक परिसर में ऊंचे तापमान के साथ, धूल भरे स्थानों में या उच्च आर्द्रता वाले स्थानों पर। यह कभी-कभी कंपन, विकिरण या अन्य प्रभावों पर विचार करने के लायक भी है।

7.1.12। सब्सक्रिप्शन 4.1.12। "पेटेंट शुद्धता के लिए आवश्यकताएँ" / पी। 2.6.1.12 GOST 34.602-89 /

यदि आपको संदेह है कि आप अन्य देशों (या हमारे देश में) में पेटेंट की गई किसी भी तकनीक का उपयोग करेंगे और पेटेंट धारक सिस्टम के मालिक के खिलाफ मुकदमा दायर कर सकता है, तो यह पैराग्राफ उन देशों की सूची को इंगित करता है जिनमें आप जाँच करना चाहते हैं पेटेंट शुद्धता के लिए।

7.1.13। खण्ड 4.1.13। "मानकीकरण और एकीकरण की आवश्यकताएं" / पी। 2.6.1.13 GOST 34.602-89 /

यह आइटम विशेष रूप से सॉफ़्टवेयर के संबंध में संदर्भ की शर्तों में भी निहित है। यह विशिष्ट प्रौद्योगिकियों के उपयोग के लिए दोनों आवश्यकताओं, और दस्तावेजों और क्लासिफायरों के मानकीकृत रूपों को इंगित करता है।

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

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

7.1.14। खंड 4.1.14। "अतिरिक्त आवश्यकताएं" / पी। 2.6.1.14 GOST 34.602-89 /

यह अनुच्छेद GOST के पाठ में पाया जाना चाहिए। उसे टिप्पणियों की जरूरत नहीं है।

7.2। ग्राहकी ४.२। "सिस्टम द्वारा निष्पादित कार्यों (कार्यों) के लिए आवश्यकताएँ" / पी। 2.6.2 GOST 34.602-89 /

यह खंड आधुनिक कंप्यूटर सिस्टम के लिए केंद्रीय है। दरअसल, सिस्टम कुछ कार्यों के प्रदर्शन के लिए बनाया गया है। अक्सर विदेशी मानकों के आधार पर और आमतौर पर मानकों के बिना बनाए गए टीके में केवल यही खंड होता है।

7.2.1। कार्यात्मक विवरण संरचना

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

यदि आपके सिस्टम में कई सबसिस्टम शामिल हैं, तो मूल रूप से टीके को सबसिस्टम के लिए कार्यों की एक सूची देनी चाहिए, और पहले से ही सबसिस्टम के लिए अलग-अलग टीके में सबसिस्टम के लिए कार्यात्मक आवश्यकताओं का विस्तार से वर्णन करना चाहिए (उन्हें अक्सर सीटीजेड कहा जाता है - एक निजी तकनीकी कार्य)।

7.2.2। उनके कार्यान्वयन के संदर्भ में कार्यों के प्रकार

वास्तव में, सभी कार्यों (या उनके कार्यों; कई कार्यों को एक बार में एक समारोह में उपस्थित किया जा सकता है) को निम्न प्रकारों में विभाजित किया जा सकता है:

• जानकारी दर्ज करना। कभी-कभी "लेखांकन जानकारी" के रूप में संदर्भित किया जाता है।
• सूचना उत्पादन।
• सूचना का स्वचालित प्रसंस्करण।

7.2.3। उनकी भूमिका के संदर्भ में कार्यों के प्रकार

कार्य सामान्य और विशेष हो सकते हैं। उदाहरण के लिए, सामान्य कार्यों में ऑब्जेक्ट्स की सूचियों के साथ काम करना, ऑब्जेक्ट कार्ड के साथ काम करना और इंटरेक्टिव मानचित्र के साथ काम करना शामिल है। ये फ़ंक्शन सभी विशेष या विशेष कार्यों के कुछ हिस्सों पर लागू हो सकते हैं।

7.2.4। आवश्यकता, लिपि की नहीं

यह मत भूलो कि टीओआर में प्रणाली और इसके निर्माण की प्रक्रिया की आवश्यकताएं हैं। स्क्रिप्ट नहीं। टीके इस सवाल का जवाब देता है कि सिस्टम को क्या करना चाहिए। सवाल करने के लिए कैसे तकनीकी डिजाइन जवाब। यदि आप तकनीकी कार्यान्वयन के बारे में विस्तार से वर्णन करना शुरू करते हैं, तो विवरण में डुबकी लगाएं और आवश्यकताओं की पूरी सूची देने में विफल रहें: हमारा मस्तिष्क विस्तृत कवरेज और विवरणों के विचार के साथ-साथ काम नहीं कर सकता है।

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

7.2.5। कार्यात्मक आवश्यकताओं

कार्यों के विवरण को तैयार करने की कुछ सिफारिशें इस प्रकार हैं:

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

7.2.6। कार्य विवरण उदाहरण

5.6। सिस्टम में एक वाहन का पंजीकरण

निम्नलिखित आवश्यकताओं को प्रस्तुत किया गया है:

1) प्रणाली को निम्नलिखित सामान्य जानकारी को ध्यान में रखने की अनुमति देनी चाहिए:

• राज्य पंजीकरण चिह्न (GRNZ);
• मालिक का नाम;
• मालिक का पता;
• वाहन डेटा अधिग्रहण सेवा से डेटा (खंड 3.3 देखें, परिशिष्ट बी);
• नोट।

2) प्रणाली को किराया भुगतान से संबंधित निम्नलिखित जानकारी को ध्यान में रखने की अनुमति देनी चाहिए (निर्दिष्ट जानकारी प्रकृति में सूचनात्मक है, वाहन के पंजीकरण कार्ड में उन्हें सीधे बदलने की संभावना नहीं है):

• वर्तमान वाहन वर्ग (खंड 3.3 देखें, परिशिष्ट ए);
• वर्तमान टैरिफ (खंड 5.1 देखें, परिशिष्ट ए);
• वर्तमान अनुबंध (खंड 5.5 देखें, परिशिष्ट ए);
• कजाकिस्तान गणराज्य के आंतरिक मामलों के मंत्रालय से जानकारी के अनुसार वाहन वर्ग;
• व्यक्तिगत खाते और उसकी स्थिति के बारे में जानकारी (खंड 3.6 देखें, परिशिष्ट ए);
• कम किराया के साथ वाहन रजिस्ट्री में होने के बारे में जानकारी (देखें खंड 3.5, परिशिष्ट ए)।

3) सिस्टम को निम्नलिखित तरीकों से वाहन के बारे में जानकारी दर्ज करने और बदलने की अनुमति देनी चाहिए:

• ऑपरेटर द्वारा मैन्युअल रूप से;
• आरएफआईडी टैग के पंजीकरण प्रणाली से जानकारी प्राप्त होने पर (खंड 1.1 देखें, परिशिष्ट बी);
• कैमरा GRNZ का उपयोग कर वाहन की पहचान करते समय।

4) सिस्टम में एक नया वाहन पंजीकृत करते समय, सिस्टम को वाहन के बारे में डेटा प्राप्त करने के लिए सेवा से वाहन के बारे में डेटा का अनुरोध करना चाहिए (पैराग्राफ 3.3 देखें, परिशिष्ट बी)। व्यक्तिगत वाहन की निर्दिष्ट जानकारी को अद्यतन करना संभव होना चाहिए।

7.3। ग्राहकी 4.3। "सुरक्षा के प्रकार के लिए आवश्यकताएँ" / पी। 2.6.3 GOST 34.602-89 /

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

वास्तव में, यह एक बहुत ही महत्वपूर्ण उपधारा है, हालांकि हर कोई इसके उद्देश्य को नहीं समझता है। यह उन परिस्थितियों का वर्णन करता है जिनके बिना विकास या कमीशन को लागू करना असंभव है। इन स्थितियों को "संपार्श्विक" के रूप में वर्णित किया गया है।

इस उपधारा को पढ़ते समय, कोई आश्चर्य करता है कि मानक के ड्राफ्ट "सॉफ्टवेयर", "भाषाई सॉफ्टवेयर", "सूचना सॉफ्टवेयर", आदि के द्वारा क्या मतलब है। GOST 34.003-90 में जवाब मांगे जाने चाहिए, जहां इन सभी शर्तों को डिक्रिप्ट किया जाता है।

7.3.1। क्लाज 4.3.1 "सॉफ्टवेयर" / पी। 2.6.3.1 GOST 34.602-89 /

उस स्थिति की कल्पना करें जिसे आपको एक प्रणाली बनाने की आवश्यकता है जिसमें आप इष्टतम मार्ग की स्वचालित गणना को लागू करना चाहते हैं। बटन "गणना मार्ग" सरल लग सकता है, लेकिन बहुत जटिल गणितीय एल्गोरिदम और गणना इसके पीछे हो सकती है। यह स्पष्ट है कि यह इस तरह के एल्गोरिदम के विकास के लायक नहीं है, पेशेवर गणितज्ञ इसमें लगे हुए हैं। यदि इस तरह के एल्गोरिदम उपलब्ध हैं, तो उनके विकास या तैयार किए गए लोगों के उपयोग की आवश्यकताएं भी लिखी जाती हैं।

7.3.2। खंड 4.3.2 "सूचना समर्थन" / पी। 2.6.3.2 GOST 34.602-89 /

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

आपको पेश करते समय, आपको ऐसी स्थिति आती है कि ग्राहक, अपने हिस्से के लिए, एक ऑपरेटर प्रदान नहीं करता है जो सिस्टम में कोई भी डेटा दर्ज करेगा, और साथ ही यह बताता है कि सिस्टम काम नहीं करता है। एक परिचित स्थिति? लेकिन अगर काम के बयान में इस इनपुट को प्रदान करने की आवश्यकता होती है, तो इस बिंदु पर ग्राहक को सीधे प्रहार करना संभव होगा। या आपको काम के लिए एक विशिष्ट पते के क्लासिफायरियर तक पहुंच की आवश्यकता है, लेकिन ग्राहक इसे आपको नहीं देता है।

इस प्रकार, इस पैराग्राफ में यह गैर-स्वचालित तरीके से सिस्टम के घटक के लिए आने वाली सूचनाओं और सूचनाओं की आवश्यकताओं को निर्दिष्ट करने के लिए समझ में आता है। स्वचालित सूचना प्रसंस्करण, DBMS का उपयोग, सिस्टम के भीतर सूचना का आदान-प्रदान अन्य वर्गों में पूरी तरह से वर्णित है।

7.3.3। खंड 4.3.3 "भाषाई समर्थन" / पी। 2.6.3.3 GOST 34.602-89 /

यह पैराग्राफ प्रदान करता है:

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

7.3.4। क्लाज 4.3.4 "सॉफ्टवेयर" / पी। 2.6.3.4 GOST 34.602-89 /

यह पैराग्राफ खरीदे गए सॉफ़्टवेयर की एक सूची प्रदान करता है, यदि उन्हें TOR के विकास के चरण में पहचाना जाता है।

7.3.5। खंड 4.3.5 "तकनीकी सहायता" / पी। 2.6.3.5 GOST 34.602-89 /

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

7.3.6। क्लाज 4.3.6 "मेट्रोलॉजिकल सपोर्ट" / पी। 2.6.3.6 GOST 34.602-89 /

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

7.3.7। खंड 4.3.7 "संगठनात्मक समर्थन" / पी। 2.6.3.7 GOST 34.602-89 /

कल्पना कीजिए कि आप स्क्रैच से एक सिस्टम बना रहे हैं। उदाहरण के लिए, यह एक नए रसद परिसर के लिए एक गोदाम प्रबंधन प्रणाली है। दूसरे शब्दों में, केवल दीवारें हैं। या आप सिस्टम को अपग्रेड कर रहे हैं, और उन परिवर्तनों को लागू करने के लिए जिन्हें आपको संगठनात्मक संरचना को संशोधित करना है। ऐसे मामलों में, आपको उन प्रक्रियाओं के संगठन के बारे में शर्तों को निर्दिष्ट करना चाहिए जिनके तहत आपके द्वारा आपूर्ति की गई प्रणाली वास्तव में काम करेगी।

7.3.8। खण्ड ४.३..8 "विधायी समर्थन" / पी। 2.6.3.8 GOST 34.602-89 /

कभी-कभी, सिस्टम को प्रबंधित करने के लिए, किसी विशेष योग्यता वाले कर्मियों की आवश्यकता होती है। इस मामले में, टीओआर में विधियों, मानदंडों और मानकों की एक सूची दी जानी चाहिए, जिसके साथ सिस्टम के साथ बातचीत करने वाले कर्मचारियों को परिचित किया जाना चाहिए।

7.3.9। अन्य प्रकार के संपार्श्विक

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

8. धारा 5 "रचना और प्रणाली के निर्माण (विकास) पर काम की सामग्री" / पी। 2.7 GOST 34.602-89 /

यह खंड संगठनात्मक है और इसे अक्सर अनुबंध में रखा जाता है। हालाँकि, ToR में यह जानकारी निर्दिष्ट की जा सकती है।

संक्षेप में, यह विकास और कार्यान्वयन की एक छोटी योजना है। इसे संकलित करते समय, मैं आमतौर पर एक तालिका देता हूं जो सभी या कुछ निम्नलिखित कॉलमों को सूचीबद्ध करती है:

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

इस अनुभाग की सामग्री का एक उदाहरण नीचे दी गई तालिका में दिया गया है।

9. धारा 6 "निगरानी और प्रणाली की स्वीकृति के लिए प्रक्रिया" / पी। 2.8 GOST 34.602-89 /

इस खंड में ग्राहक द्वारा प्रणाली की स्वीकृति की प्रक्रिया का विस्तार से वर्णन किया गया है: क्या परीक्षण किए जाने चाहिए, इन परीक्षणों में क्या शामिल होंगे, क्या दस्तावेजों का परीक्षण किया जाएगा, कैसे टिप्पणियों को समाप्त किया जाएगा और समाप्त किया जाएगा।

9.1। ग्राहकी 6.1। "सिस्टम और इसके घटकों के प्रकार, संरचना, मात्रा और परीक्षण के तरीके" / पी। 2.8.1 GOST 34.602-89 /

आमतौर पर, मैं यहां परीक्षणों की सूची का संकेत देता हूं और उल्लेख करता हूं कि परीक्षण के तरीके "टेस्ट प्रोग्राम एंड मेथोडोलॉजी" में दिए जाएंगे, जो मुख्य परीक्षण मामलों, परीक्षण लिपियों का विवरण है।

आइए हम परीक्षणों के प्रकारों पर ध्यान दें। परीक्षणों के प्रकार, उनकी संरचना, दस्तावेजों की आवश्यकताएं GOST 34.603-92 “सूचना प्रौद्योगिकी द्वारा स्थापित की जाती हैं। स्वचालित प्रणालियों के परीक्षण के प्रकार। " इसलिए, इस खंड और तकनीकी परियोजना को विकसित करते समय, इस मानक को संदर्भित करना सुनिश्चित करें, यहां हम केवल मुख्य बिंदुओं की व्याख्या करेंगे।

आइए समझने की कोशिश करें कि परीक्षण किस प्रकार के हैं:

1. परीक्षण निम्न प्रकारों में विभाजित हैं:

• प्रारंभिक।
• परीक्षण संचालन।
• स्वीकृति।

2. प्रारंभिक (और आंशिक रूप से स्वीकृति) परीक्षण बदले में विभाजित हैं:

• ( ).
• ( ).

परीक्षणों को विभिन्न चरणों में क्यों विभाजित किया जाता है? सबसे पहले, क्योंकि GOST 34.603-92 आंतरिक और बाहरी स्वीकृति के बीच अंतर नहीं करता है, परीक्षणों का हिस्सा एक ग्राहक के बिना किया जा सकता है। दूसरे, एक अनुक्रमिक परीक्षण प्रक्रिया वर्णित है, भाग द्वारा भाग, और फिर सब कुछ एकीकृत है।

आइए सरल शब्दों में परीक्षण प्रक्रिया का वर्णन करने का प्रयास करें:

1. प्रणाली के कुछ हिस्सों के प्रारंभिक स्वायत्त परीक्षण। यदि सिस्टम में कई सबसिस्टम या बड़े मॉड्यूल हैं, तो सिस्टम के हिस्सों को व्यक्तिगत रूप से परीक्षण किया जाता है। आमतौर पर, इस तरह के परीक्षण को स्वायत्त रूप से किया जाता है, अर्थात् आसन्न प्रणालियों के साथ एकीकरण के बिना। यदि सिस्टम सरल है, तो यह चरण सुरक्षित रूप से छोड़ दिया जा सकता है।

2. एक पूरे के रूप में प्रणाली की प्रारंभिक स्वायत्त परीक्षण।पूरे सिस्टम को एक स्वायत्त मोड में एक जटिल में परीक्षण किया गया है, अर्थात्, आसन्न सिस्टम के साथ एकीकरण के बिना। आसन्न प्रणालियों से जुड़े कार्यों का परीक्षण नहीं किया जाता है। एक चरम मामले में, "स्टब्स" डाल दिया जाता है (एकीकरण का अनुकरण) या डेटाबेस डेटा के साथ पूर्व-आबादी है जो बाहरी स्रोतों से आना चाहिए।

3. प्रारंभिक व्यापक परीक्षण। सिस्टम को एक एकीकृत तरीके से परीक्षण किया जाता है, अर्थात आसन्न सिस्टम के साथ बातचीत में। इस रूप में, सिस्टम को ट्रायल ऑपरेशन के लिए ग्राहक को हस्तांतरित किया जाता है।

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

5. स्वीकृति परीक्षण। यह आखिरी तरह का चेक है। मुझे बताओ, सभी कमियों को दूर करने के बाद परीक्षण ऑपरेशन सुचारू रूप से औद्योगिक में क्यों नहीं जाएगा? तो यह आमतौर पर होता है। लेकिन उच्च अंकल को यह देखना होगा कि सिस्टम वास्तव में काम करता है, इसे "महसूस" करने के लिए। स्वीकृति परीक्षण उनके लिए उच्च आयोग के लिए अभिप्रेत है। इस प्रकार, स्वीकृति परीक्षण मुख्यतः आयोग की स्थिति में प्रारंभिक परीक्षणों से भिन्न होते हैं।

इसके अलावा इस पैराग्राफ में दस्तावेजों को दर्शाया गया है जिसमें परीक्षण के तरीके दिए जाएंगे:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2। सदस्यता 6.2। "चरणों द्वारा काम की स्वीकृति के लिए सामान्य आवश्यकताएं" / पी। 2.8.2 GOST 34.602-89 /

इस खंड में, मैं आमतौर पर संकेत देता हूं:

1. किसके क्षेत्र पर और किसके उपकरण पर परीक्षण किए जाएंगे: ग्राहक या ठेकेदार।
2. परीक्षण कैसे आयोजित किए जाएंगे (उदाहरण के लिए, कि दस्तावेजों की जाँच की जाएगी, उपयोगकर्ता इंटरफ़ेस तत्वों की उपस्थिति, स्क्रिप्ट पर काम किया जाता है) का एक सामान्य विवरण।
3. प्रतिभागियों की सूची।
4. परीक्षा परिणाम तैयार करने वाले दस्तावेजों की सूची:
   
   
   • प्रारंभिक और स्वीकृति परीक्षणों के लिए, यह एक परीक्षण रिपोर्ट है जो चेक और उनके परिणामों की एक सूची प्रदान करती है।
   • ट्रायल ऑपरेशन के लिए - एक ट्रायल ऑपरेशन जर्नल।

10. धारा 7 "सिस्टम को संचालन में डालने के लिए स्वचालन वस्तु तैयार करने की रचना और सामग्री के लिए आवश्यकताएं" / p। 2.9 GOST 34.602-89 /

इस खंड में वर्णित प्रक्रिया को अक्सर कार्यान्वयन के रूप में संदर्भित किया जाता है। कृपया ध्यान दें कि ये कार्य खंड 5 में दिए गए हैं "रचना और प्रणाली के निर्माण (विकास) पर काम की सामग्री" । लेकिन, खंड 5 में उनका केवल संक्षेप में उल्लेख किया गया है, और यहां एक विस्तृत विवरण दिया गया है।

एक वस्तु को तैयार करते समय, एक नियम के रूप में, निम्नलिखित कार्य किया जाना चाहिए:

1. आवश्यक होने पर पुनर्गठन, नए कर्मचारियों की भर्ती।
2. स्टाफ प्रशिक्षण।
3. वेब अनुप्रयोगों के लिए: साइट के सामान्य वर्गों का विकास और उपयोगकर्ता समझौता (व्यक्तिगत डेटा के प्रसंस्करण के लिए सहमति)।
4. निर्देशिका और अन्य पृष्ठभूमि जानकारी भरना।
5. पुराने सिस्टम से डेटा ट्रांसफर करें।
6. औद्योगिक सर्वर पर प्रणाली की तैनाती।
7. आसन्न सिस्टम के साथ एकीकरण को कॉन्फ़िगर करें।
8. एक पहुंच प्रणाली स्थापित करना और खाते बनाना।

इनमें से कुछ बिंदुओं को महान विवरण में वर्णित किया जाना चाहिए, विशेष रूप से डेटा ट्रांसफर और निर्देशिकाओं को भरने के संबंध में।

11. धारा 8 "दस्तावेज़ीकरण आवश्यकताएं" / पी। 2.10 GOST 34.602-89 /

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

GOST 34 के अनुसार स्वचालन परियोजना का प्रलेखन निम्नलिखित मानकों द्वारा विनियमित है:

• GOST 34.201-89 स्वचालित सिस्टम बनाते समय दस्तावेजों की पूर्णता और पदनाम।
• RD 50-34.698-90 दिशानिर्देश। सूचना प्रौद्योगिकी। स्वचालित प्रणालियों के लिए मानकों और दिशानिर्देशों का एक सेट। स्वचालित प्रणाली। दस्तावेजों की सामग्री के लिए आवश्यकताएँ।
• संदर्भ की शर्तों के लिए - GOST 34.602-89, जिस पर हम अभी चर्चा कर रहे हैं।

पहला मानक (GOST 34.201-89) प्रलेखन की एक सूची और संरचना प्रदान करता है। दूसरे में - आरडी 50-34.698-90 - निम्नलिखित दस्तावेजों की सामग्री इंगित की गई है:

• प्रारंभिक डिजाइन और तकनीकी परियोजनाओं के दस्तावेज।
• पूर्व-डिजाइन चरणों में दस्तावेज विकसित किए गए।
• संगठनात्मक और प्रशासनिक दस्तावेज (अधिनियम, प्रोटोकॉल, आदि)

11.1 प्रलेखन संरचना की विशेषताएं

आवश्यक दस्तावेजों की सूची तैयार करते समय, वे आमतौर पर RD 50-34.698-90 को देखते हैं और आवश्यक लोगों का चयन करते हैं। उसी समय, बहुत सारी गलतियाँ की जाती हैं, क्योंकि प्रलेखन में एक जटिल संरचना होती है, जिसे GOST 34.201-89 में वर्णित किया गया है।

आइए कुछ नियमों की पहचान करने की कोशिश करें जो दस्तावेजों की एक सूची तैयार करने में मदद करेंगे।

1. प्रत्येक चरण में प्रलेखन का अपना सेट होता है।

प्रत्येक चरण में प्रलेखन का अपना सेट होता है। यह समझना बहुत जरूरी है। डिजाइन चरणों में परिचालन दस्तावेजों के विकास को निर्धारित करना आवश्यक नहीं है और इसके विपरीत। यह विशुद्ध रूप से औपचारिक पेपर निकला, जिसे आप काफी समय देंगे। और अगर सिस्टम के विकास के अंत तक "यूजर गाइड", आमतौर पर कोई नहीं बनाता है (हालांकि मैं ऐसे आंकड़े मिला हूं), तो "स्वचालित कार्यों का विवरण", जिसमें प्रोग्रामर के लिए स्क्रिप्ट आमतौर पर दी जाती हैं, विकास पूरा होने के बाद लगातार तैयार की जाती हैं। आरडी 50-34.698-90 पढ़ते समय, किसी को यह आभास हो सकता है कि कुछ दस्तावेजों में अतिव्यापी सामग्री है: यह इस तथ्य के कारण भी है कि दस्तावेज़ विभिन्न चरणों के लिए अभिप्रेत हैं।

चूँकि कुछ दस्तावेज़ों को या तो एक या दूसरे चरण में विकसित किया जा सकता है, GOST 34.201-89, पुनरावृत्ति से बचने के लिए, अलग-अलग प्रदान करता है, उदाहरण के लिए, दस्तावेज़ों की एक सूची जो तकनीकी डिज़ाइन और कार्य प्रलेखन दोनों के चरण में जारी की जा सकती है, और अलग से, दस्तावेज़ों की सूची इन चरणों में से प्रत्येक अलग से। इस प्रकार, जब किसी एक चरण के लिए दस्तावेजों की सूची तैयार की जाती है, तो आपको मानक के कई खंडों में दस्तावेजों की सूचियों को देखना होगा।

भ्रमित न होने के लिए, मैंने एक एक्सेल स्प्रेडशीट को संकलित किया जिसमें फिल्टर का उपयोग करके आप किसी विशेष चरण के लिए दस्तावेजों की पूरी सूची तुरंत प्रदर्शित कर सकते हैं।

2. दस्तावेजों को विषयों (परियोजना के कुछ हिस्सों) में विभाजित किया गया है।

GOST 34 में सिस्टम-वाइड समाधानों के साथ-साथ संगठनात्मक, तकनीकी, गणितीय, सॉफ़्टवेयर, सूचना समर्थन (हम ऊपर दिए गए समर्थन के प्रकारों के बारे में बात करते हैं ) का वर्णन करने वाले दस्तावेज़ शामिल हैं । RD 50-34.698-90 में इन दस्तावेजों को परियोजना के कुछ हिस्सों (विषयों) द्वारा टूटने के साथ दिया गया है। दस्तावेज़ के उद्देश्य को निर्धारित करने के लिए आपको हमेशा इस पर ध्यान देना चाहिए।

3. दस्तावेजों को जोड़ा जा सकता है।

GOST 34.201-89 सीधे इंगित करता है कि किन मामलों में एक दस्तावेज़ दूसरे में शामिल है। ऐसा इसलिए किया जाता है ताकि एक या दो पन्नों के साथ कोई पतित दस्तावेज न बचे। यदि कुछ का वर्णन करने की आवश्यकता है, लेकिन वॉल्यूम बहुत छोटा है, तो पाठ को किसी अन्य दस्तावेज़ में शामिल करना सबसे अच्छा है। ज्यादातर मामलों में, "तकनीकी डिजाइन के लिए व्याख्यात्मक नोट" जैसे एक दस्तावेज है, जिसमें आप अनुभाग जोड़ सकते हैं।

4. ऑपरेशनल और डिज़ाइन अनुमान अलग-अलग हाइलाइट किए गए हैं।

परिचालन और डिज़ाइन अनुमानों से संबंधित दस्तावेजों की एक सूची के साथ तालिका के विभिन्न स्तंभों में GOST 34.201-89 के संकलक।

डिजाइन के अनुमानों में निर्माण और बिजली के काम को नियंत्रित करने वाले दस्तावेज शामिल हैं: अनुमान, खरीद योजना, चित्र और विद्युत आरेख।

परिचालन दस्तावेजों में ऐसे दस्तावेज शामिल हैं जो सिस्टम के उपयोग और रखरखाव का मार्गदर्शन करते हैं: मैनुअल और निर्देश, सामग्री और डेटा की सूची, दस्तावेज जिसमें ऑपरेशन के दौरान उल्लंघन के बारे में जानकारी होती है।

11.2 दस्तावेजों की सूची के डिजाइन की विशेषताएं

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

प्रलेखन नियमों में, मैं आमतौर पर निम्नलिखित स्तंभों के साथ एक तालिका देता हूं:

• स्टेज।
• दस्तावेज़ का नाम।
• नोट: विकास मानक, उद्देश्य, सारांश और दस्तावेज़ की मुख्य विशेषताएं इंगित करता है।

11.3 उदाहरण प्रलेखन की सूची

एक जटिल प्रणाली को लागू करने के लिए एक बड़ी परियोजना के लिए, प्रलेखन की एक बड़ी सूची की आवश्यकता हो सकती है। हम नीचे दी गई तालिका में ऐसी सूची का एक उदाहरण देते हैं।

12. धारा 9 "विकास के स्रोत" / पी। 2.11 GOST 34.602-89 /

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

यदि कई स्रोत हैं, तो उन्हें उप-वर्गों में विभाजित किया जाना चाहिए, उदाहरण के लिए:

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

निष्कर्ष

बेशक, GOST 34 के अनुसार संदर्भ की शर्तों की तैयारी को आसान और सरल नहीं कहा जा सकता है। और इसलिए नहीं कि GOST खराब है, बल्कि GOST आपको पूरी परियोजना के माध्यम से सोचने के लिए बनाता है, सभी छोटी चीजों को चित्रित करता है। लेकिन एक अच्छी तरह से लिखा टीओआर परियोजना की आधी सफलता है।

टिप्पणियों में लिखें यदि आप कुछ को स्पष्ट या पूरक करना आवश्यक मानते हैं। लेख में बदलाव अवश्य करें।

लेखक द्वारा अन्य लेख पढ़ें:

• सूचना प्रणाली के विकास में पूर्व-डिज़ाइन सर्वेक्षण।
• अस्पताल के निर्माण के उदाहरण पर आईपी (सूचना प्रणाली) के सफल डिजाइन का रहस्य।
• सूचना प्रणाली के डिजाइन पर कुछ नोट्स।