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

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

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

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

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

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

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

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

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

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

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

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

अपने स्वयं के अनुभव से, मैं सिफारिश कर सकता हूं कि ठेकेदार का ध्यान अन्य मुद्दों के अलावा, ToR में विचार करने की आवश्यकता के लिए तैयार है:

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

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

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