सिस्टम विकास के सर्वर और इंफ्रास्ट्रक्चर से संबंधित कानूनी मुद्दे क्या हैं?

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

IT सिस्टम में इंफ्रास्ट्रक्चर क्या होता है

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

इंफ्रास्ट्रक्चर की समस्याएं प्रोजेक्ट को जलाने के विषय में विस्तृत जानकारी

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

सर्वर साइज़िंग की गलती से विवाद कैसे उत्पन्न होता है

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

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

मामले की मूल बात, अस्पष्ट विनिर्देशों के प्रति विक्रेता की जिम्मेदारी की सीमा है

हालांकि, ऐसे विवाद की मूल बात यह हो सकती है कि, “विनिर्देशों में स्पष्ट रूप से उल्लेखित नहीं होने वाले मुद्दों के प्रति, विक्रेता को कितनी जिम्मेदारी उठानी चाहिए।” इस बात को ध्यान में रखते हुए, निम्नलिखित लेख की सामग्री से आपको कई सुझाव मिल सकते हैं।

https://monolith.law/corporate/system-development-specs-function[ja]

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

सर्वर साइज़िंग की गलतियों से होने वाली समस्याओं को रोकने के उपाय

ऐसी समस्याओं को रोकने के लिए, प्रोग्राम का लागू करना, सोर्स कोड का वर्णन जैसे कार्य और इंफ्रास्ट्रक्चर के आसपास के माहौल की व्यवस्था को समान करना महत्वपूर्ण है। विचार किए जा सकने वाले कुछ उपाय निम्नलिखित हैं।

सर्वर साइज़िंग की जिम्मेदारी को स्पष्ट रूप से ठहराना

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

विकास की आवश्यकताओं को विस्तृत रूप से व्याख्या करना, और परिवर्तन प्रबंधन को पूरी तरह से करना

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

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

परियोजना की प्रकृति के अनुसार विकास मॉडल का चयन करना

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

सारांश

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