स्वीकृति के बाद सिस्टम में दोष सामने आने पर क्या कार्यवाही होती है?

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

लेकिन वास्तविक समस्या यह है कि, टेस्टिंग प्रक्रिया और स्वीकृति परीक्षण के उत्तीर्ण होने के समय ऐसे बग या कमियां जो खोजे नहीं जा सके थे, वे बाद के ऑपरेशनल चरण में पता चल सकते हैं। एक बार डिलीवरी स्वीकार कर लेने के बाद, कानूनी रूप से हम क्या मांग सकते हैं?

स्वीकृति परीक्षण के बाद या टेस्ट प्रक्रिया के बाद भी बग बचे होने में कुछ अजीब नहीं है

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

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

स्वीकृति या टेस्ट जैसे चरणों में, हर तरह के बग और कमियों की खोज करना वास्तविक नहीं होता है, और वास्तव में उपयोग शुरू करने के बाद विभिन्न समस्याएं सामने आ सकती हैं, यह बात समझना चाहिए कि यह आईटी सिस्टम है।

ऋण स्वयं को पूरा करने का उपचार प्राप्त करना सामान्य होता है

तो ऐसी मुसीबतों का सामना करने पर, हमें कैसे निपटना चाहिए? हम कानूनी क्रम के अनुसार इसे व्यवस्थित करेंगे।

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

सिस्टम विकास के अनुबंध में, जब तक कुछ विशेष व्यवस्था तैयार नहीं होती, प्रोग्राम के कार्यान्वयन के नियम नागरिक कानून के ठेका अनुबंध के नियमों को लागू करते हैं। ठेका अनुबंध क्या होता है, इसके बारे में हमने निम्नलिखित लेख में विस्तार से व्याख्या की है।

और ठेका अनुबंध में, “काम की समाप्ति” ऋण की पूर्ति की आवश्यकता होती है। यहां “काम की समाप्ति” वास्तव में क्या कहती है, इसके बारे में हमने निम्नलिखित लेख में विस्तार से व्याख्या की है।

यहां हमने पिछले न्यायाधीश के उदाहरण में, ठेका अनुबंध में “काम की समाप्ति” का अर्थ होता है, यदि हम सिस्टम विकास के संदर्भ में कहें, तो विकास प्रक्रिया के सभी चरणों का समापन। और हमने यह भी समझाया है कि विकास प्रक्रिया के सभी चरणों के समापन के बाद बग्स और समस्याओं का मुद्दा, ठेका अनुबंध में दोष गारंटी की जिम्मेदारी का मुद्दा बनता है।

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

दोष गारंटी जिम्मेदारी के आधार पर जिम्मेदारी का पीछा करने का मार्ग

तो, दोष गारंटी जिम्मेदारी के आधार पर विक्रेता से सहयोग की मांग करने के मामले में, हमें क्या और किस क्रम में विचार करना चाहिए? आइए नीचे जांच करें।

सबसे पहले, बग या खराबी की गंभीरता और गहराई की परीक्षा करें

बग या खराबी बाद में सामने आती है, और यदि यह कानूनी रूप से “दोष” है, तो कुछ भी गारंटी की मांग करने के लिए, बग या खराबी की गंभीरता मुद्दा बन जाती है। कानूनी दोष की समस्या मूल रूप से

1. बग या खराबी के रूप में कहा जा सकता है, लेकिन यह हल्की है, और कानूनी रूप से “दोष” नहीं कहा जा सकता।
2. कानूनी “दोष” के लिए योग्य है, लेकिन समझौते के उद्देश्य को पूरा करना संभव है।
3. कानूनी “दोष” के लिए योग्य है, और समझौते के उद्देश्य को पूरा करना भी संभव नहीं है।

ये तीन पैटर्न में विभाजित होते हैं। दोष गारंटी जिम्मेदारी के आधार पर जिम्मेदारी का पीछा करने की संभावना को विभाजित करने वाली चीज़ 1 और 2 की सीमा है, और दोष गारंटी जिम्मेदारी के आधार पर समझौते को खत्म करने की संभावना को विभाजित करने वाली चीज़ 2 और 3 की सीमा है।

धारा 634

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

2. आदेशकर्ता, दोष की मरम्मत के बदले में, या उसके साथ, क्षतिपूर्ति की मांग कर सकता है। इस मामले में, धारा 533 के नियमों का पालन किया जाएगा।

धारा 635

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

वैसे, इन “दोष” के चरणबद्ध भेद के बारे में, हमने नीचे दिए गए लेख में विस्तार से विवरण दिया है।

https://monolith.law/corporate/defect-warranty-liability[ja]

अगला कदम, विक्रेता से मांग करने वाली चीज़ों को स्पष्ट करना

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

वैसे, खत्म करने के अलावा, दोष गारंटी जिम्मेदारी के अंतर्गत मांग की जा सकने वाली चीज़ों में, क्षतिपूर्ति की मांग और दोष मरम्मत की मांग आदि शामिल हैं।

अन्य ध्यान देने योग्य बिंदु

संविदा का रद्द करना आदि, कानूनी कार्य करते समय, तरीके पर भी ध्यान देना चाहिए

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

विवाद की बजाय, समाधान के लिए वार्ता का रूप लेना चाहिए

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

बग और कमियों को, सुविधाओं की कमी से अलग सोचना चाहिए

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

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

सारांश

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