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

डिज़ाइन संदर्भ की शर्तें। यह क्या है, इसकी आवश्यकता क्यों है, कहां शुरू करना है और यह कैसा दिखना चाहिए?

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

मुझसे अक्सर पूछा जाता है: “संदर्भ की शर्तों को कैसे विकसित किया जाए स्वचालित प्रणाली? " इसी तरह के विषय पर विभिन्न मंचों पर लगातार चर्चा की जाती है। यह प्रश्न इतना व्यापक है कि संक्षेप में इसका उत्तर देना असंभव है। इसलिए, मैंने इस विषय पर एक बड़ा लेख लिखने का फैसला किया। लेख पर काम करने की प्रक्रिया में, मुझे एहसास हुआ कि एक लेख में सब कुछ डालने से काम नहीं चलेगा, क्योंकि यह 50 पन्नों से कम हो जाएगा और इसे 2 भागों में तोड़ने का फैसला किया गया है:

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

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

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

मुझे लगता है कि अब पाठक के पास प्रश्न होने चाहिए:

• और संदर्भ की शर्तों को विकसित करना हमेशा असंभव क्यों है?
• क्या कोई मानक, कार्यप्रणाली, सिफारिशें हैं? उन्हें कहाँ से लाएँ?
• संदर्भ की शर्तें किसको विकसित करनी चाहिए? क्या इस व्यक्ति को कोई विशेष ज्ञान होना चाहिए?
• कैसे समझें कि संदर्भ की शर्तें अच्छी तरह से तैयार हैं या नहीं?
• किसके खर्च पर इसे विकसित किया जाना चाहिए, और क्या यह आवश्यक भी है?

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

संदर्भ की शर्तें क्या है?

अब हम पहली बात यह पता लगाने के लिए करेंगे कि यह किस प्रकार का जानवर है, "तकनीकी असाइनमेंट"।

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

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

अगर किसी की दिलचस्पी है कि मैं किस GOST के बारे में बात कर रहा हूं, तो वे यहां हैं:

• GOST 2.114-95 डिज़ाइन प्रलेखन के लिए एकीकृत प्रणाली। तकनीकी स्थिति;
• GOST 19.201-78 कार्यक्रम प्रलेखन की एकीकृत प्रणाली। संदर्भ की शर्तें। सामग्री और डिजाइन के लिए आवश्यकताएँ;
• GOST 34.602-89 सूचना प्रौद्योगिकी। स्वचालित प्रणालियों के लिए मानकों का एक सेट। एक स्वचालित प्रणाली के निर्माण के लिए संदर्भ की शर्तें।

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

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

यह मुख्य है, लेकिन केवल एक ही है। यह सबसे महत्वपूर्ण बात से निपटने का समय है: वादे के अनुसार सब कुछ क्रम में रखें।

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

• कार्यक्षमता के लिए आवश्यकताएँ;
• सुरक्षा और पहुंच आवश्यकताएँ;
• कर्मचारियों की योग्यता की आवश्यकताएं;
• .... आदि आप उनके बारे में उल्लिखित GOST में पढ़ सकते हैं (और नीचे मैं भी उन पर थोड़ा और विस्तार से विचार करूंगा)।

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

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

1. आवश्यकता तो होनी ही चाहिए स्पष्ट;
2. आवश्यकता तो होनी ही चाहिए विशिष्ट;
3. आवश्यकता तो होनी ही चाहिए कसौटी;

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

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

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

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

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

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

व्यवहार में हमारे पास क्या है? यह देखने के लिए मनोरंजक है कि जब संदर्भ की शर्तों को निदेशक के पास मंजूरी के लिए लाया जाता है, जो तकनीकी शब्दावली, डेटा प्रकारों और उनके अर्थों का विवरण, डेटाबेस की संरचना इत्यादि के साथ पूरा होता है। वह, ज़ाहिर है, इसमें तल्लीन करने की कोशिश करता है, क्योंकि आपको तर्क करना है, लाइनों के बीच परिचित शब्दों को खोजने की कोशिश करना और श्रृंखला को नहीं खोना है। व्यावसायिक आवश्यकताएं। क्या, एक परिचित स्थिति? और यह कैसे समाप्त होता है? एक नियम के रूप में, इस तरह के टीके को मंजूरी दी जाती है, फिर लागू किया जाता है, और 80% मामलों में तब यह काम के तथ्य के अनुरूप नहीं होता है, क्योंकि उन्होंने बहुत सी चीजों को बदलने का फैसला किया, उन्हें फिर से परिभाषित किया, गलत समझा, ऐसा नहीं किया, आदि। आदि और फिर काम की डिलीवरी के बारे में श्रृंखला शुरू होती है। "और यहाँ इसकी आवश्यकता नहीं है", लेकिन "यह हमारे लिए काम नहीं करेगा", "यह बहुत जटिल है", "यह असुविधाजनक है", आदि। क्या यह परिचित है? !! इसलिए मुझे पता है, मुझे नियत समय में शंकु भरना था।

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

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

क्या आपको एक तकनीकी कार्य की आवश्यकता है? एक तकनीकी परियोजना?

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

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

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

हम इस सवाल का अध्ययन जारी रखते हैं: "संदर्भ की शर्तों में क्या आवश्यकताएं शामिल होनी चाहिए?"

सूचना प्रणाली के लिए आवश्यकताओं का निरूपण। संदर्भ की शर्तों की संरचना

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

किसी भी गतिविधि की तरह, आवश्यकताओं का निरूपण (और होना चाहिए) चरणों में विभाजित किया जाना चाहिए। हर चीज का अपना समय होता है। यह कठिन बौद्धिक कार्य है। और, यदि आप इसे अपर्याप्त ध्यान से व्यवहार करते हैं, तो परिणाम उचित होगा। विशेषज्ञ के अनुमानों के अनुसार, संदर्भ की शर्तों को विकसित करने की लागत 30-50% हो सकती है। मेरी भी यही राय है। हालांकि 50 शायद बहुत अधिक है। आखिरकार, संदर्भ की शर्तों को विकसित किया जाने वाला अंतिम दस्तावेज नहीं है। आखिरकार, तकनीकी डिजाइन भी होना चाहिए। यह परिवर्तन विकास के दौरान परियोजना टीमों द्वारा उपयोग किए जाने वाले विभिन्न स्वचालन प्लेटफार्मों, दृष्टिकोण और प्रौद्योगिकियों के कारण है। उदाहरण के लिए, यदि हम C ++ जैसी शास्त्रीय भाषा में विकसित होने की बात कर रहे हैं, तो हम विस्तृत तकनीकी डिजाइन के बिना नहीं कर सकते। यदि हम 1 सी प्लेटफॉर्म पर एक प्रणाली शुरू करने के बारे में बात कर रहे हैं, तो डिजाइन के साथ स्थिति कुछ अलग है, जैसा कि हमने ऊपर देखा (हालांकि, जब खरोंच से सिस्टम विकसित हो रहा है, तो इसे शास्त्रीय योजना के अनुसार बनाया गया है)।

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

1. सामान्य जानकारी;
2. प्रणाली के निर्माण (विकास) के उद्देश्य और उद्देश्य;
3. स्वचालन वस्तुओं की विशेषताएं;
4. सिस्टम आवश्यकताएँ;
5. एक प्रणाली बनाने के लिए काम की संरचना और सामग्री;
6. प्रणाली नियंत्रण और स्वीकृति प्रक्रिया;
7. सिस्टम को संचालन में लगाने के लिए स्वचालन वस्तु तैयार करने पर रचना और काम की सामग्री के लिए आवश्यकताएं;
8. प्रलेखन आवश्यकताओं;
9. विकास के स्रोत।

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

धारा 1. सामान्य जानकारी।

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

धारा 2. प्रणाली के निर्माण (विकास) का उद्देश्य और उद्देश्य।

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

धारा 3. स्वचालन वस्तुओं की विशेषता।

अनुभाग 4. सिस्टम आवश्यकताएँ

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

खंड 5. एक प्रणाली बनाने के लिए रचना और काम की सामग्री

खंड 6. प्रणाली नियंत्रण और स्वीकृति प्रक्रिया

इसके साथ व्यवहार में क्या करना है

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

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

खंड 7. सिस्टम को संचालन में डालने के लिए स्वचालन वस्तु तैयार करने पर रचना और काम की सामग्री के लिए आवश्यकताएं

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

अनुभाग 8. प्रलेखन आवश्यकताएँ

इसके साथ व्यवहार में क्या करना है

डेवलपर और सिस्टम के ग्राहक द्वारा विकसित किए जाने वाले सेटों और दस्तावेजों के प्रकारों की सूची

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

खंड 9. विकास स्रोत

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

और इसलिए, हमने उन सभी अनुभागों की जांच की, जिन्हें संदर्भ की शर्तों में शामिल किया जा सकता है। "वे कर सकते हैं," और नहीं "Obliged," ठीक है क्योंकि किसी भी दस्तावेज़ को परिणाम प्राप्त करने के लिए विकसित किया जाना चाहिए। इसलिए, यदि यह आपके लिए स्पष्ट है कि एक अलग अनुभाग आपको परिणाम के करीब नहीं लाएगा, तो आपको इसकी आवश्यकता नहीं है और आपको इस पर समय बिताने की आवश्यकता नहीं है।

लेकिन मुख्य बात के बिना: कोई भी सक्षम तकनीकी कार्य पूरा नहीं हुआ है। मैं यह नोट करना चाहता हूं कि व्यवहार में इस तरह के संदर्भ की शर्तें पाई जाती हैं और कैसे! ऐसे आंकड़े हैं जो सभी वर्गों में पानी को अलग करने में सक्षम हैं, सामान्य शर्तों में सामान्य आवश्यकताओं का वर्णन करते हैं, और दस्तावेज़ बहुत वजनदार है, और बहुत सारे चतुर शब्द हैं, और यहां तक \u200b\u200bकि ग्राहक इसे पसंद कर सकता है (यानी वह इसे अनुमोदित करेगा)। लेकिन इस पर काम करना काम नहीं कर सकता है, अर्थात्। वहाँ से थोड़ा व्यावहारिक लाभ है। ज्यादातर मामलों में, ऐसे दस्तावेज तब पैदा होते हैं जब आपको विशेष रूप से संदर्भ की शर्तों के लिए बहुत अधिक धन प्राप्त करने की आवश्यकता होती है, और आपको इसे जल्दी और बिना विवरण में जाने की आवश्यकता होती है। और विशेष रूप से अगर यह ज्ञात है कि चीजें आगे नहीं बढ़ेंगी, या पूरी तरह से अलग लोग करेंगे। सामान्य तौर पर, सिर्फ बजट के विकास के लिए, विशेष रूप से राज्य के लिए।

दूसरे लेख में हम केवल खंड 4 "सिस्टम आवश्यकताएँ" के बारे में बात करेंगे, और विशेष रूप से हम समझ, सहमति और परीक्षण के कारणों के लिए आवश्यकताओं को तैयार करेंगे।

आवश्यकताएं स्पष्ट, विशिष्ट और परीक्षण योग्य क्यों होनी चाहिए।

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

आवश्यकता का प्रकार

गलत शब्दांकन

प्रयोगशाला की तैयारी

"एलसी सॉफ्टवेयर के मॉडल" विषय पर व्याख्यान सामग्री पढ़ें। GOST 19.102-77 के अनुसार जीवन चक्र चरण। समस्या का विवरण "सॉफ्टवेयर और आईटी के विकास और मानकीकरण"।

1. प्रकाशनों में संबंधित वर्गों का अध्ययन करना।

सैद्धांतिक भाग। तकनीकी विशिष्टताओं का विकास

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

तकनीकी विशिष्टताओं के विकास की प्रक्रिया

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

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

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

1. सामान्य

1.1। संदर्भ की शर्तों को GOST 19016-78 के अनुसार A4 और A3 प्रारूप की शीट पर GOST 2.301-68 के अनुसार निकाला जाता है, एक नियम के रूप में, शीट के क्षेत्रों को भरने के बिना। शीट की संख्या (पृष्ठ) पाठ के ऊपर शीट के शीर्ष पर चिपकाए गए हैं।

1.2। अनुमोदन पत्रक और शीर्षक पृष्ठ GOST 19.104-78 के अनुसार तैयार किए गए हैं। सूचना भाग (एनोटेशन और सामग्री), परिवर्तन के पंजीकरण की शीट को दस्तावेज़ में शामिल नहीं करने की अनुमति है।

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

1.4। संदर्भ की शर्तों में निम्नलिखित अनुभाग शामिल होने चाहिए:

परिचय;

नाम और गुंजाइश;

विकास का आधार;

नियुक्ति विकास;

एक कार्यक्रम या सॉफ्टवेयर उत्पाद के लिए तकनीकी आवश्यकताएं;

तकनीकी और आर्थिक संकेतक;

चरणों और विकास के चरणों;

नियंत्रण और स्वीकृति का आदेश;

आवेदन।

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

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

२.२. अनुभाग में "नाम और कार्यक्षेत्र" नाम को दर्शाता है, कार्यक्रम या सॉफ्टवेयर उत्पाद के दायरे का संक्षिप्त विवरण और वह वस्तु जिसमें प्रोग्राम या सॉफ्टवेयर उत्पाद का उपयोग किया जाता है।

2.3। "विकास के लिए आधार" अनुभाग में संकेत दिया जाना चाहिए:

वह दस्तावेज (दस्तावेज) जिसके आधार पर विकास किया जा रहा है। इस तरह के दस्तावेज़ एक योजना, आदेश, अनुबंध, आदि के रूप में कार्य कर सकते हैं;

संगठन जिसने इस दस्तावेज़ को मंजूरी दी और इसकी स्वीकृति की तारीख;

नाम और (या) विकास विषय का प्रतीक।

2.4। अनुभाग "पदनाम पदनाम" में, कार्यक्रम या सॉफ्टवेयर उत्पाद के कार्यात्मक और परिचालन पदनाम को इंगित किया जाएगा।

2.5। अनुभाग "एक कार्यक्रम या सॉफ्टवेयर उत्पाद के लिए तकनीकी आवश्यकताओं" में निम्नलिखित उपसमूह शामिल होने चाहिए:

कार्यात्मक विशेषताओं के लिए आवश्यकताएँ;

विश्वसनीयता की आवश्यकताएं;

परिचालन की स्थिति;

तकनीकी उपकरणों की संरचना और मापदंडों के लिए आवश्यकताएं;

सूचना और सॉफ्टवेयर संगतता आवश्यकताओं;

लेबलिंग और पैकेजिंग आवश्यकताओं;

परिवहन और भंडारण के लिए आवश्यकताएँ;

विशेष आवश्यकताएं।

2.5.1। उपधारा "कार्यात्मक विशेषताओं के लिए आवश्यकताएं" प्रदर्शन किए गए कार्यों की संरचना, इनपुट और आउटपुट डेटा के संगठन, समय विशेषताओं आदि की आवश्यकताओं को इंगित करना चाहिए।

2.5.2। उपधारा "विश्वसनीयता आवश्यकताओं" विश्वसनीय कामकाज सुनिश्चित करने के लिए आवश्यकताओं (स्थिर कामकाज सुनिश्चित करने, इनपुट और आउटपुट जानकारी का नियंत्रण, विफलता के बाद वसूली समय, आदि) को इंगित करेगा।

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

2.5.4। उपधारा में "तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ" तकनीकी साधनों की आवश्यक संरचना को उनके संकेत के साथ इंगित करती हैं। तकनीकी विनिर्देश.

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

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

2.5.7 उपखंड में "परिवहन और भंडारण के लिए आवश्यकताएं" परिवहन की स्थिति, भंडारण स्थान, भंडारण की स्थिति, भंडारण की स्थिति, भंडारण की अवधि विभिन्न स्थितियों में सॉफ्टवेयर उत्पाद के लिए संकेत दिया जाना चाहिए।

2.5.8। "तकनीकी और आर्थिक संकेतक" खंड में संकेत दिया जाना चाहिए: अनुमानित आर्थिक दक्षता, अनुमानित वार्षिक मांग, सर्वोत्तम घरेलू और विदेशी मॉडल या एनालॉग्स की तुलना में विकास के आर्थिक लाभ।

2.6. अनुभाग में "विकास के चरण और चरण" विकास के आवश्यक चरणों, चरणों और कार्य की सामग्री (कार्यक्रम दस्तावेजों की एक सूची जिसे विकसित, सहमत और अनुमोदित किया जाना चाहिए), साथ ही एक नियम, विकास का समय और निष्पादकों को निर्धारित करना है।

2.7। अनुभाग "नियंत्रण और स्वीकृति की प्रक्रिया" कार्य की स्वीकृति के लिए परीक्षण के प्रकार और सामान्य आवश्यकताओं को इंगित करना चाहिए।

2.8. संदर्भ की शर्तों के संदर्भ में, यदि आवश्यक हो, तो निम्नलिखित दिया जाएगा:

विकास की पुष्टि करने वाले अनुसंधान और अन्य कार्यों की सूची;

एल्गोरिदम योजनाएं, टेबल, विवरण, औचित्य, गणना और अन्य दस्तावेज जो विकास में उपयोग किए जा सकते हैं;

विकास के अन्य स्रोत।

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

तकनीकी विशिष्टताओं के विकास के उदाहरण अनुलग्नक B और C में दिए गए हैं।

सुरक्षा के सवाल

1. एक सॉफ्टवेयर जीवन चक्र मॉडल की अवधारणा दें।

2. सॉफ्टवेयर विकास के चरणों को दें।

3. समस्या और पूर्व-परियोजना अनुसंधान के बयान में क्या शामिल है?

4. सॉफ्टवेयर उत्पाद के लिए कार्यात्मक और परिचालन आवश्यकताओं को सूचीबद्ध करें।

5. तकनीकी विशिष्टताओं के विकास के लिए नियमों की सूची बनाएं।

6. तकनीकी विशिष्टताओं के मुख्य खंड क्या हैं।

परिशिष्ट A

नौकरी के विकल्प

प्रयोगशाला काम नंबर 1-5 एक ही विकल्प के लिए किया जाता है।

1. एक कार्यक्रम मॉड्यूल विकसित करें "छात्र के प्रदर्शन के लिए लेखांकन।" कार्यक्रम मॉड्यूल डीन के कार्यालय के डीन, डिप्टी डीन और कर्मचारियों द्वारा सत्र में छात्र के प्रदर्शन के संचालन के लिए बनाया गया है। छात्र के प्रदर्शन के बारे में जानकारी उनके अध्ययन की पूरी अवधि में संग्रहीत की जानी चाहिए और पूर्ण पाठ्यक्रम और डिप्लोमा की खुराक के प्रमाण पत्रों के संकलन में उपयोग की जानी चाहिए।

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

3. एक सॉफ्टवेयर मॉड्यूल विकसित करने के लिए "कॉम्बीनेटरियल-ऑप्टिमाइज़ेशन समस्याओं का समाधान।" मॉड्यूल में न्यूनतम लंबाई चक्र (ट्रैवलिंग सेल्समैन समस्या) खोजने, सबसे छोटा रास्ता खोजने और न्यूनतम कनेक्टिंग ट्री खोजने के लिए एल्गोरिदम होना चाहिए।

4. एक सॉफ्टवेयर मॉड्यूल विकसित करें "मैट्रिक्स का प्रसंस्करण।" मॉड्यूल में पंक्तियों और स्तंभों द्वारा मैट्रिक्स तत्वों के सोम्स और उत्पादों की खोज के लिए एल्गोरिदम होना चाहिए, साथ ही मैट्रिक्स में औसत, न्यूनतम और अधिकतम मूल्यों की गणना करना चाहिए।

5. विंडोज ऑर्गनाइज़र एप्लिकेशन को विकसित करें। आवेदन को रिकॉर्ड करने, स्टोर करने और व्यक्तियों और संगठनों के पते और फोन नंबर, साथ ही शेड्यूल, मीटिंग आदि के लिए डिज़ाइन किया गया है। आवेदन किसी भी कंप्यूटर उपयोगकर्ता के लिए है।

6. एक विंडोज एप्लिकेशन "कैलकुलेटर" विकसित करें। आवेदन किसी भी उपयोगकर्ता के लिए है और इसमें सभी गणितीय कार्य (प्राथमिकताओं के संबंध में) और अधिमानतः (लेकिन आवश्यक नहीं) कई गणितीय कार्य होने चाहिए।

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

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

9. एक कार्यक्रम मॉड्यूल "ड्राई क्लीनिंग" विकसित करें। सेवा के लिए पंजीकरण करते समय, एक आवेदन भरा जाता है, जो मालिक का नाम, उत्पाद का विवरण, सेवा का प्रकार, आदेश की प्राप्ति की तारीख और सेवा की लागत को इंगित करता है। काम पूरा होने के बाद, एक रसीद प्रिंट की जाती है।

10. एक सॉफ्टवेयर मॉड्यूल विकसित करने के लिए "यातायात उल्लंघन के लिए लेखांकन।" प्रत्येक कार (और उसके मालिक) के लिए, उल्लंघन की एक सूची डेटाबेस में संग्रहीत की जाती है। प्रत्येक उल्लंघन के लिए, दिनांक, समय, उल्लंघन का प्रकार और जुर्माना का आकार दर्ज किया जाता है। सभी जुर्मानाों का भुगतान करते समय, कार डेटाबेस से निकाल दी जाती है।

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

12. सॉफ्टवेयर मॉड्यूल "पीबीएक्स ग्राहकों का कार्ड इंडेक्स" विकसित करने के लिए। कार्ड फ़ाइल में फोन और उनके मालिकों के बारे में जानकारी होती है। यह भुगतान (मासिक और समय-आधारित) पर ऋणों को ठीक करता है। यह माना जाता है कि समय-आधारित स्थानीय टेलीफोन बिलिंग पहले ही शुरू की जा चुकी है।

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

14. पुस्तकों (लेखक, शीर्षक, प्रकाशक, प्रकाशन का वर्ष, मूल्य) के बारे में जानकारी युक्त एक कार्यक्रम मॉड्यूल "बुकस्टोर" विकसित करें। खरीदार को अपनी ज़रूरत की किताबों के लिए एक आवेदन मिलता है, अगर कोई नहीं है, तो उसे डेटाबेस में दर्ज किया जाता है और स्टोर पर आवश्यक किताबें आने पर सूचित किया जाता है।

15. एक सॉफ्टवेयर मॉड्यूल "पार्किंग" विकसित करें। कार्यक्रम में कार के ब्रांड, उसके मालिक, प्रवेश की तारीख और समय, पार्किंग की लागत, छूट, भुगतान की बकाया राशि आदि के बारे में जानकारी है।

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

श्रमजीवी कार्य K १

प्रोग्रामिंग के लिए एक संरचनात्मक दृष्टिकोण के साथ सॉफ्टवेयर विकास के चरण। स्टेज "संदर्भ की शर्तें"

काम का उद्देश्य: तकनीकी विनिर्देश लिखने के नियमों से खुद को परिचित करें।

प्रयोगशाला की तैयारी

"एलसी सॉफ्टवेयर के मॉडल" विषय पर व्याख्यान सामग्री पढ़ें। GOST 19.102-77 के अनुसार जीवन चक्र चरण। समस्या का विवरण "सॉफ्टवेयर और आईटी के विकास और मानकीकरण"।

  प्रकाशनों में संबंधित अनुभागों की जांच करें।

सैद्धांतिक भाग। तकनीकी विशिष्टताओं का विकास

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

तकनीकी विशिष्टताओं के विकास की प्रक्रिया

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

  संदर्भ की शर्तों को GOST 19016-78 के अनुसार A4 और A3 प्रारूप की शीट पर GOST 2.301-68 के अनुसार निकाला जाता है, एक नियम के रूप में, शीट के क्षेत्रों को भरने के बिना। शीट की संख्या (पृष्ठ) पाठ के ऊपर शीट के शीर्ष पर चिपकाए गए हैं। अनुमोदन पत्रक और शीर्षक पृष्ठ GOST 19.104-78 के अनुसार तैयार किए गए हैं। जानकारी भाग (एनोटेशन और सामग्री), परिवर्तन के पंजीकरण की शीट को दस्तावेज़ में शामिल नहीं करने की अनुमति है। किसी प्रोग्राम या प्रोग्राम उत्पाद को विकसित करने के बाद के चरणों में, तकनीकी रियर में परिवर्तन और परिवर्धन करने के लिए, इसके अलावा एक अतिरिक्त जारी किया जाता है। संदर्भ की शर्तों के लिए पूरक के समन्वय और अनुमोदन उसी तरह से किया जाता है जैसे संदर्भ की शर्तों के लिए स्थापित किया गया है। संदर्भ की शर्तों में निम्नलिखित अनुभाग शामिल होने चाहिए:

  परिचय; नाम और कार्यक्षेत्र;

  विकास का आधार; विकास का उद्देश्य; एक कार्यक्रम या सॉफ्टवेयर उत्पाद के लिए तकनीकी आवश्यकताएं; तकनीकी और आर्थिक संकेतक; विकास के चरणों और चरणों; नियंत्रण और स्वीकृति प्रक्रिया; आवेदन।

कार्यक्रम या सॉफ्टवेयर उत्पाद की सुविधाओं के आधार पर, अनुभागों की सामग्री को स्पष्ट करने, नए अनुभागों को पेश करने या अलग-अलग लोगों को संयोजित करने की अनुमति है। यदि आवश्यक हो, तो इसे संदर्भ की शर्तों में आवेदन शामिल करने की अनुमति है। 2. अनुभागों की सामग्री

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

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

  कार्यात्मक आवश्यकताओं; विश्वसनीयता की आवश्यकताएं; परिचालन की स्थिति; तकनीकी उपकरणों की संरचना और मापदंडों की आवश्यकताएं;

  सूचना और सॉफ्टवेयर संगतता के लिए आवश्यकताएं;

  लेबलिंग और पैकेजिंग आवश्यकताओं; परिवहन और भंडारण के लिए आवश्यकताएं; विशेष आवश्यकताएं।

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

  2.5.8। "तकनीकी और आर्थिक संकेतक" खंड में संकेत दिया जाना चाहिए: अनुमानित आर्थिक दक्षता, अनुमानित वार्षिक मांग, सर्वोत्तम घरेलू और विदेशी मॉडल या एनालॉग्स की तुलना में विकास के आर्थिक लाभ।

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

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

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

कार्य क्रम

  सॉफ़्टवेयर उत्पाद के लिए उसके संस्करण के अनुसार संदर्भ की शर्तें विकसित करें (परिशिष्ट A में विकल्प देखें)। GOST 19.106-78 के अनुसार डिज़ाइन कार्य। एमएस कार्यालय का उपयोग करने के लिए पंजीकरण पर। काम सौंपें और रक्षा करें।

लैब रिपोर्ट सुरक्षा

  प्रयोगशाला के काम की रिपोर्ट एसटीपी के आधार पर जारी की जानी चाहिए और इसमें निम्नलिखित संरचनात्मक तत्व शामिल हैं:

  शीर्षक पृष्ठ; पाठ भाग; आवेदन: एक सॉफ्टवेयर उत्पाद के लिए तकनीकी विनिर्देश विकसित किए हैं।

  रिपोर्ट के पाठ भाग में बिंदु शामिल होने चाहिए:

  कार्य की स्थिति; निष्पादन आदेश।

  प्रयोगशाला रिपोर्ट को सहेजना एक फ़ाइल के रूप में शिक्षक को परिणाम प्रस्तुत करना और शिक्षक के प्रश्नों के उत्तर में अर्जित कौशल का प्रदर्शन करना है।

सुरक्षा के सवाल

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

संदर्भ

  बेद्रिना एस.एल., सॉफ्टवेयर विकास और मानकीकरण। - व्लादिवोस्तोक: VSUES, 2006 का पब्लिशिंग हाउस। ब्लागोडात्सिख V.A., वोलेन V.A., पॉस्कोकलोव K.F. सॉफ्टवेयर विकास का मानकीकरण। - एम: वित्त और सांख्यिकी, 2003. GOST 19.102-77 ESPD। विकास के चरण

परिशिष्ट A

नौकरी के विकल्प

प्रयोगशाला काम नंबर 1-5 एक ही विकल्प के लिए किया जाता है।

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

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

परिशिष्ट बी

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

1. परिचय

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

  कार्यक्रम "कम्प्यूटिंग सिस्टम के कंप्यूटर विज्ञान और सॉफ्टवेयर" विभाग के पाठ्यक्रम के आधार पर विकसित किया गया है। काम का नाम:

  "एक आयामी सरणी को छाँटने का कार्यक्रम।"

  ठेकेदार: BcstSoft कंपनी। सह-निष्पादक: स्रोत

3. नियुक्ति  कार्यक्रम "कंप्यूटर विज्ञान" पाठ्यक्रम में "एक आयामी सरणियों के प्रसंस्करण" विषय का अध्ययन करते समय स्कूली बच्चों द्वारा उपयोग करने का इरादा है। 4. एक कार्यक्रम या सॉफ्टवेयर उत्पाद के लिए आवश्यकताएँ 4.1. कार्यात्मक आवश्यकताएँ 4.1.1. कार्यक्रम को निम्नलिखित कार्य करने की क्षमता प्रदान करनी चाहिए:

  सरणी और सरणी के आकार में प्रवेश करना; सरणी और मेमोरी स्टोरेज; छँटाई विधि का चयन; छँटाई विधि का एक पाठ विवरण उत्पादन; छँटाई परिणाम का उत्पादन।

  4.1.2। स्रोत डेटा:

  एक पूर्णांक द्वारा निर्दिष्ट सरणी आकार; एक सरणी।

  इनपुट और आउटपुट डेटा का संगठन।

  इनपुट डेटा कीबोर्ड से आता है। आउटपुट स्क्रीन पर प्रदर्शित किया जाता है और, यदि आवश्यक हो, मुद्रित किया जाता है।

  विश्वसनीयता आवश्यकताओं

  इनपुट जानकारी के नियंत्रण के लिए प्रदान करें। सिस्टम के साथ काम करने पर उपयोगकर्ता के गलत कार्यों को रोकने के लिए।

  तकनीकी उपकरणों की संरचना और मापदंडों के लिए आवश्यकताएं।

  सिस्टम आईबीएम-संगत व्यक्तिगत कंप्यूटरों पर चलना चाहिए। न्यूनतम कॉन्फ़िगरेशन:

  प्रोसेसर प्रकार पेंटियम और उच्चतर; रैंडम एक्सेस मेमोरी की मात्रा 32 एमबी या उससे अधिक; 40 एमबी मुक्त हार्ड डिस्क स्थान।

  अनुशंसित कॉन्फ़िगरेशन:

  प्रोसेसर प्रकार पेंटियम II 400; रैम क्षमता 128 एमबी; आपकी हार्ड ड्राइव पर खाली जगह की मात्रा 60 एमबी है।

  4.4। सॉफ्टवेयर संगतता आवश्यकताएँ।
कार्यक्रम विन 32 ऑपरेटिंग सिस्टम (विंडोज 95/98/2000 / ME / XP, आदि) के परिवार के तहत चलना चाहिए।

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

  पाँच पत्रक पर व्याख्यात्मक नोट जिसमें विकास का विवरण है। उपयोगकर्ता मैनुअल।

परिशिष्ट बी

उदाहरण 2"मास्को संस्थान की इमारतों के लिए गर्मी की आपूर्ति के परिचालन प्रेषण नियंत्रण के लिए एक स्वचालित प्रणाली के मॉड्यूल" के विकास के लिए संदर्भ की शर्तों को विकसित करने के लिए।

1. परिचय

यह कार्य परियोजना के भाग के रूप में किया गया है "मॉस्को इंस्टीट्यूट की इमारतों के लिए इलेक्ट्रिक हीट सप्लाई के परिचालन प्रेषण के लिए स्वचालित प्रणाली"। 2. आधारके लिए डिज़ाइन

  इस कार्य के लिए आधार मार्च 10, 2003 का सं। 1234 है।

  काम का नाम:

  "मास्को संस्थान की इमारतों के लिए गर्मी की आपूर्ति के परिचालन प्रेषण नियंत्रण के लिए एक स्वचालित प्रणाली का मॉड्यूल"।

  निष्पादनकर्ता: OJSC "सॉफ्टवेयर निर्माण प्रयोगशाला"।

  सह-निष्पादक: नहीं।

3. विकास का उद्देश्य  मॉस्को संस्थान भवनों को प्रदान करने के लिए मुख्य मापदंडों की स्थिति की निगरानी और परिचालन समायोजन के लिए एक मॉड्यूल का निर्माण। 4. तकनीकी आवश्यकताओं  4.1। कार्यात्मक विशेषताओं के लिए आवश्यकताएँ। 4.1.1। किए गए कार्यों की संरचना। विकसित सॉफ्टवेयर प्रदान करना चाहिए:

  गर्मी, गर्म और पर जानकारी का संग्रह और विश्लेषण ठंडा पानी  सभी थर्मल आउटपुट पर गर्मी मीटर SA-94 के अनुसार; आरटी 1 और आरटी 2 (एसएमएमई और टीसी विभाग द्वारा विकसित) प्रकार के एयर हीटिंग और कंडीशनिंग सिस्टम के लिए नियंत्रण उपकरणों से जानकारी का संग्रह और विश्लेषण; स्वीकार्य सीमा के भीतर मापदंडों को खोजने और जब सहिष्णुता से परे जाते हैं तो सिग्नलिंग के विषय पर जानकारी का प्रारंभिक विश्लेषण;

  आगे के काम के लिए सिफारिशें जारी करना;

  मापदंडों के एक सेट के अनुसार वर्तमान स्थिति का प्रदर्शन - चक्रीय रूप से लगातार (24-घंटे ऑपरेशन मोड), अन्य मापदंडों के नियंत्रण की आवृत्ति को बनाए रखते हुए; शीतलक प्रवाह पर जानकारी का दृश्य:

  मीटर रीडिंग के समान वर्तमान; पिछले दिन, सप्ताह, महीने में संचय के साथ - प्रति दिन और सप्ताह की जानकारी के लिए एक घंटे के चार्ट के रूप में; दैनिक खपत - प्रति माह जानकारी के लिए।

आपूर्ति वेंटिलेशन नियंत्रण उपकरणों के लिए, वर्तमान जानकारी में आपूर्ति प्रणाली की संख्या और इसके अपने संकेतक के लिए जारी किए गए सभी पैरामीटर शामिल होने चाहिए। अनुरोध पर, आंतरिक सेटिंग्स बनाई जाती हैं। रिपोर्टिंग अवधि के अंत में, सिस्टम को डेटा संग्रह करना होगा। 4.1.2। इनपुट और आउटपुट डेटा का संगठन। सिस्टम का प्रारंभिक डेटा संस्थान के परिसर में स्थापित सेंसर से मूल्यों के रूप में आता है। इनमान डिस्पैचर के कंप्यूटर पर प्रदर्शित किए जाते हैं। प्राप्त जानकारी का विश्लेषण करने के बाद, नियंत्रण केंद्र का ऑपरेटर परिसर में हीटिंग और वेंटिलेशन को विनियमित करने वाले उपकरणों के लिए आवश्यक पैरामीटर सेट करता है। नियंत्रण उपकरणों के लिए कुछ मापदंडों को स्वचालित रूप से सेट करना भी संभव है। सिस्टम का उपयोग करने का मुख्य तरीका दैनिक कार्य है। 4.2। विश्वसनीयता आवश्यकताएँ। विश्वसनीयता सुनिश्चित करने के लिए, सेंसर से प्राप्त डेटा की शुद्धता को सत्यापित करना आवश्यक है। 4.3। संचालन और तकनीकी उपकरणों की संरचना और मापदंडों के लिए परिचालन की स्थिति और आवश्यकताएं। काम करने की प्रणाली के लिए, एक जिम्मेदार ऑपरेटर को आवंटित किया जाना चाहिए। तकनीकी उपकरणों की संरचना और मापदंडों के लिए आवश्यकताएं सिस्टम की रूपरेखा डिजाइन के चरण में निर्दिष्ट की जाती हैं। 4.4। सूचना और सॉफ्टवेयर संगतता के लिए आवश्यकताएँ। कार्यक्रम विंडोज 98 / NT / 2000 प्लेटफार्मों पर चलना चाहिए।

4.5। परिवहन और भंडारण के लिए आवश्यकताएँ।

कार्यक्रम एक लेजर भंडारण माध्यम पर दिया जाता है। सॉफ्टवेयर प्रलेखन को इलेक्ट्रॉनिक रूप से और हार्ड कॉपी में वितरित किया जाता है। 4.6। विशेष आवश्यकताएं:

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

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

1. अग्निशमन सेवा और आपातकालीन प्रतिक्रिया सेवाओं की सूचना और तकनीकी बुनियादी ढांचे के विकास के लिए उपकरणों की आपूर्ति के लिए संदर्भ की शर्तें। राज्य अनुबंध का विषय

   संदर्भ की शर्तें

   आग सेवा और आपातकालीन प्रतिक्रिया सेवाओं की सूचना और तकनीकी बुनियादी ढांचे के विकास के लिए उपकरणों की आपूर्ति के लिए।

2. डिजाइन और निर्माण कार्यों के एक जटिल के लिए संदर्भ की शर्तें

   संदर्भ की शर्तें

   2.1। इस तकनीकी असाइनमेंट के तहत काम का प्रदर्शन टर्नकी निर्माण परियोजना के पुनर्निर्माण (रूपांतरण, पुनर्विकास) पर सर्वेक्षण, डिजाइन और निर्माण कार्यों के पूरे परिसर के ठेकेदार द्वारा प्रदर्शन का तात्पर्य करता है।

3. साइट शीट के निर्माण पर काम के लिए संदर्भ की शर्तें

   संदर्भ की शर्तें

   rD 50-34.698-90 की आवश्यकताएं "विधायी निर्देश। सूचना प्रौद्योगिकी। स्वचालित प्रणालियों के लिए मानकों और दिशानिर्देशों का एक सेट।

4. प्रमुख मरम्मत के लिए अपार्टमेंट इमारतों की तकनीकी स्थिति के निरीक्षण के लिए संदर्भ की शर्तें। कम वर्तमान सिस्टम। संचार, अलार्म, सुरक्षा

   संदर्भ की शर्तें

   एक स्वचालित फायर अलार्म सिस्टम, साथ ही एक चेतावनी और निकासी नियंत्रण प्रणाली, जीवन समर्थन प्रणालियों के निर्माण का एक अभिन्न अंग है

5. तकनीकी असाइनमेंट लॉट नंबर 1 गो-टू-वोकेशनल स्कूल के पुस्तकालय के लिए विदेशी साहित्य की आपूर्ति "सेवकागट्टु"

   संदर्भ की शर्तें

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

6. निष्कर्ष के अधिकार के लिए इलेक्ट्रॉनिक रूप में 624-ई में खुली नीलामी पर प्रलेखन के तकनीकी विनिर्देश

   संदर्भ की शर्तें

   2. अवधि और आवश्यकताओं (या) माल की गुणवत्ता की गारंटी की मात्रा के लिए: वितरित माल के लिए वारंटी अवधि कमीशन की तारीख से कम से कम 24 महीने होनी चाहिए।