ग्राहक के दृष्टिकोण से एक सॉफ्टवेयर उत्पाद के लिए तकनीकी विनिर्देश (टीओआर) का विकास। बग पर काम करना

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

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

शोधन:

1. तकनीकी कार्य नहीं लिखे गए हैं (संकलित, तैयार, निष्पादित, आदि), लेकिन विकसित , GOST 34.602-89 का कम से कम खंड 1.2 देखें;
2. यदि ग्राहक और ठेकेदार GOSTs की आवश्यकताओं के अनुसार निर्देशित होते हैं, तो, सिद्धांत रूप में, वे पूरी तरह से विपरीत राय नहीं कर सकते हैं। यदि बातचीत "अवधारणाओं के अनुसार" की जाती है - जैसा कि अब प्रथागत है - तो, ​​ज़ाहिर है, "विचारों के बहुलवाद" के बिना करने का कोई तरीका नहीं है।

ठेकेदार निर्मित समाधान की कार्यक्षमता के बारे में अपने दायित्वों को जितना संभव हो सके उतना औपचारिक रूप देने के लिए सबसे विस्तृत टीओआर में दिलचस्पी ले सकता है।

तीनधारी तलवार:

1. एक विस्तृत रूप से विस्तृत तकनीकी कार्य एक तकनीकी परियोजना बन जाती है, जो सामान्य तौर पर खराब नहीं होती है, लेकिन ठेकेदार को एक विस्तृत विस्तृत तकनीकी कार्य को विकसित करने के लिए इतना समय और पैसा कौन देगा?
2. जिम्मेदार कलाकार हमेशा "कम शब्दों - कम सवालों" के बाद से तकनीकी कार्य की मात्रा को कम करना चाहता है। और काम कम। इसके अलावा, तकनीकी कार्य के चरण में उत्पाद, कार्यक्रम या स्वचालित प्रणाली की तकनीकी उपस्थिति की भविष्यवाणी करना बहुत मुश्किल है, इसलिए, एक विशिष्ट बहाना है "यह और जिसे तकनीकी परियोजना के चरण में निर्दिष्ट किया जाना चाहिए";
3. ठेकेदार को यह नहीं भूलना चाहिए कि वह न केवल कार्यात्मक आवश्यकताओं के कार्यान्वयन के बारे में दायित्वों को वहन करता है, बल्कि सामान्य आवश्यकताओं - विश्वसनीयता, सुरक्षा आदि की आवश्यकताओं को भी पूरा करता है। यह सूची के लिए कोई मतलब नहीं है, क्योंकि उनमें से काफी हैं और वे सभी एक ही GOST 34.602-89 में विस्तार से वर्णित हैं।

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

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

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

अनिवार्य रूप से सही है, केवल यह टीके नहीं होगा, लेकिन एक परिचालन-तकनीकी नोट, टीटीजेड, आवेदन, विशलिस्ट के साथ पत्र - कुछ अन्य कार्यात्मक आवश्यकताओं की तरह। अब अशुद्धियों के बारे में: आप मॉड्यूल और सबसिस्टम की अवधारणाओं को नहीं मिला सकते हैं, क्योंकि सबसिस्टम एक ही सिस्टम है, केवल छोटा है। सिस्टम की तरह सबसिस्टम, सभी प्रकार के समर्थन, सभी समान सामान्य आवश्यकताओं को शामिल करता है, और मॉड्यूल सिर्फ एक प्रोग्राम है "भंडारण, अनुवाद, अन्य प्रोग्राम मॉड्यूल के साथ एकीकरण और रैम में लोड करने के लिए इरादा एक प्रोग्राम का एक कार्यात्मक पूर्ण टुकड़ा है [से] GOST 19781-90 की तालिका 1 की पृष्ठ संख्या 15 ""

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

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

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

एक दीर्घकालिक सहयोग के लिए, ठेकेदार सभी अंगों से चिपकेगा, जब तक कि निश्चित रूप से, ग्राहक जिम्मेदार नहीं है ... हम सर्पिल मॉडल को GOST 34.602-89 के खंड 1.7 से बदल देंगे और समान मानक के परिशिष्ट 1 के खंड 11 को स्पष्ट करेंगे। सातवें पैराग्राफ में:

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

चरणों और कतारों की अवधारणा मिश्रित है। स्वचालित प्रणालियों के संबंध में: स्टेज - एक परमाणु ऊर्जा संयंत्र बनाने के चरण का हिस्सा, कार्य की प्रकृति की एकता के कारणों और (या) अंतिम परिणाम या प्रदर्शन करने वालों की विशेषज्ञता [GOST 34.003-90 के खंड से] कतार - एक परमाणु ऊर्जा संयंत्र का हिस्सा जिसके लिए परमाणु ऊर्जा संयंत्र बनाने के लिए तकनीकी कार्य। सामान्य तौर पर, अलग प्रवेश तिथियां और कार्यान्वित कार्यों का एक सेट स्थापित किया जाता है [GOST के खंड 4.5 से 34.003-90] नौवें पैराग्राफ के अनुसार:

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

टीके की सामग्री के साथ पृष्ठों के संकलन के साथ यह सभी पहल क्यों? क्या GOST 19.201 है, GOST 34.602 और अन्य मानक हैं जिनमें तकनीकी कार्यों की संरचना और सामग्री स्पष्ट रूप से और सख्ती से रखी गई है, राज्य द्वारा वैध है, जिसमें व्यावहारिक रूप से कुछ भी नहीं है, जबकि ग्राहक और ठेकेदार के विवेक पर अतिरिक्त अनुभागों, उपखंडों, पैराग्राफों और उप-अनुच्छेदों को लागू करने की अनुमति है। दसवें पैराग्राफ के अनुसार:

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

यह पूरी तरह से समझ से बाहर है: आखिरकार, वह जो संगीत खरीदता है और ग्राहक भुगतान करता है। कोई कलाकार उस पर कुछ भी कैसे थोप सकता है? यहां केवल आपसी "पार्टियों के पूर्ण गैर-प्रतिरोध वाले उत्पाद के रूप में सहमति" संभव है ... ग्यारहवें पैराग्राफ के अनुसार:

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

एक धारा में बह गए आँसू:

1. यह तय करना हमारे लिए ठीक नहीं है कि यह अच्छा है या बुरा, क्योंकि MIL सहित सभी मौजूदा विदेशी मानक, कवरेज के विस्तार और व्यापकता के मामले में GOST 34 वें के करीब भी नहीं थे;
2. GOST 34.602 का सॉफ्टवेयर उत्पादों से कोई संबंध नहीं है , क्योंकि "यह मानक विभिन्न प्रकार की गतिविधियों (प्रबंधन, डिजाइन, अनुसंधान, आदि) के स्वचालन के लिए स्वचालित प्रणालियों (एएस) पर लागू होता है, जिसमें उनके संयोजन शामिल हैं, और संरचना, सामग्री को स्थापित करता है। दस्तावेज़ के डिजाइन के लिए नियम "सिस्टम के निर्माण (विकास या आधुनिकीकरण) के लिए संदर्भ की शर्तें" (इसके बाद - परमाणु ऊर्जा संयंत्रों के लिए संदर्भ की शर्तें)।

सच है, GOST 19.201 के अनुसार विकसित GOST 34.602 की व्यक्तिगत आवश्यकताओं को GOST 19.201 के अनुसार अलग-अलग जोड़ना उचित है, जो कि GOST 19.201 द्वारा स्वयं को मना नहीं किया गया है - "कार्यक्रम या सॉफ़्टवेयर उत्पाद की सुविधाओं के आधार पर, यह वर्गों की सामग्री को स्पष्ट करने, नए अनुभागों को संयोजित करने या संयोजन करने की अनुमति देता है। उन्हें [GOST 19.201-78 के खंड 1.4 से]। ” चौदहवें बड़े पैराग्राफ के अनुसार:

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

यह सब GOST 19.201 और GOST 34.602 दोनों के लिए प्रदान नहीं किया गया है, लेकिन एक उपधारा है "सिस्टम कर्मियों की संख्या और योग्यता और इसके संचालन की विधि के लिए आवश्यकताएँ", जो सॉफ्टवेयर के लिए ToR में जोड़ना और कर्मियों की श्रेणियों का विस्तार से वर्णन करना उचित है। और यहां तक ​​कि भूमिकाएं ... और GOST 34.602 संगठनात्मक समर्थन के लिए आवश्यकताएं प्रदान करता है - वे पूरी तरह से चारों ओर मुड़ सकते हैं और कल्पना पर लगाम दे सकते हैं। नीचे सूचीबद्ध सब कुछ आरडी 50-34.698-90 में विस्तार से वर्णित है। यदि आप विवरण में रुचि रखते हैं, तो टिप्पणियों में प्रश्न पूछें। निष्कर्ष में:

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

और अंत में:

1. "विधायी" टीके को ग्राहक द्वारा स्वयं विकसित किया जाता है यदि वह रक्षा मंत्रालय या किसी अन्य कानून प्रवर्तन एजेंसी का प्रतिनिधित्व करता है;
2. निविदा दस्तावेज ठेकेदार द्वारा विकसित किया जाता है, जिसे स्पष्ट रूप से निविदा जीतनी होती है। क्षमा करें, लेकिन ये जीवन की वास्तविकताएं हैं ...

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