जो सॉफ्टवेयर आप प्रिंट करेंगे उसका कोड किसका होना चाहिए?

कार्यशील स्क्रीन और वितरित उत्पाद समान नहीं हैं

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

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

आपके लिए आवश्यक डिलीवरी मॉडल निर्धारित करता है

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

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

कोड के आगे कौन सी जानकारी शामिल की जानी चाहिए?

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

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

अलग-अलग निर्भरताएँ और उपयोग की शर्तें

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

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

एक छोटे स्वीकृति परीक्षण के साथ डिलीवरी सत्यापित करें

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

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

अक्सर पूछे जाने वाले सवाल

क्या केवल स्रोत कोड प्राप्त करना ही पर्याप्त है?

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

क्या प्रत्येक सॉफ़्टवेयर में कोड डिलीवरी अपेक्षित है?

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

आपूर्तिकर्ता स्विचिंग का परीक्षण कैसे करें?

स्वीकृति परीक्षण में एक नई अधिकृत टीम को डिलीवरी पैकेज के साथ परीक्षण वातावरण स्थापित करने और नमूना डेटा निर्यात करने में शामिल करें।