MONOLITH LAW OFFICE+81-3-6262-3248हप्ताका दिनहरू 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

आईटी सिस्टमको डाटाबेससँग सम्बन्धित कानूनी समस्याहरूको बारेमा

IT

आईटी सिस्टमको डाटाबेससँग सम्बन्धित कानूनी समस्याहरूको बारेमा

जब तपाईं IT प्रणालीसँग सम्बन्धित कानूनी समस्याहरूको बारेमा जान्न खोज्नुहुन्छ, त्यहाँ व्यवस्थित कानूनी ज्ञानको माग हुन्छ, तर साथै, IT प्रणालीका घटकहरूको बारेमा ज्ञान पनि महत्वपूर्ण हुन्छ। यस लेखमा, हामी IT प्रणाली कस्ता भागहरूले बनेको छ र ती भागहरू कसरी एकआपसमा सम्बन्धित छन् भन्ने कुरा व्यवस्थित गर्नेछौं, र प्रयोगकर्ताहरूले सजिलै देख्न नसक्ने डाटाबेससँग विशेष रूपमा सम्बन्धित कानूनी समस्याहरूको बारेमा व्याख्या गर्नेछौं।

आईटी सिस्टम “डिस्प्ले” र “लजिक” बाट बनेको हुन्छ

आईटी सिस्टमको “डिस्प्ले” के हो?

आईटी सिस्टमको संरचना बुझ्ने प्रयासमा, सबैभन्दा पहिले ध्यान जाने कुरा डिस्प्ले तर्फको बाहिरी रूप हो। निश्चित रूपमा, सामान्य सिस्टम विकासको प्रक्रियामा पनि, कार्यक्षमता निर्धारण पछि आमतौरमा “डिस्प्ले डिजाइन” र “डिस्प्ले ट्रान्जिशन”को व्यवस्थापन गरिन्छ। यस्ता डिस्प्लेमा देखिने बाहिरी रूपहरू सिस्टम विकासका लागि आदेश दिने प्रयोगकर्ताहरूका लागि पनि स्पष्ट रूपमा ध्यान जाने क्षेत्र हुन्, र प्रयोगकर्ता र विक्रेताबीचको सञ्चार सबैभन्दा बढी हुने क्षेत्र पनि हो। तलको लेखमा, सिस्टम विकासको सम्पूर्ण प्रक्रियामा प्रयोगकर्ताले विक्रेतासँग सहकार्य गर्नुपर्ने “सहयोग दायित्व”को बारेमा विस्तृत विवरण दिइएको छ।

https://monolith.law/corporate/user-obligatory-cooporation[ja]

यस लेखमा, प्रयोगकर्ताले सिस्टम विकासमा लाग्नुपर्ने सहयोग दायित्वको रूपमा मुख्यतया, मूल डिजाइन (अर्थात् डिस्प्ले) लगायतका चरणहरूमा विक्रेतासँग सहकार्य गर्नुपर्ने आवश्यकताको बारेमा व्याख्या गरिएको छ।

आईटी सिस्टममा “डिस्प्ले” सामान्यतया HTML वा CSS जस्ता कम्प्युटर भाषाहरूका नियमहरू अनुसार लेखिन्छ। आईटी सिस्टमको “डिस्प्ले”को कुरा गर्दा, “फ्रन्टएन्ड”, “UI (प्रयोगकर्ता इन्टरफेस)” जस्ता विभिन्न नामहरूले चिनिन्छ, तर यसको मुख्य विषय प्रयोगकर्ताले देख्ने “प्रयोगमा सजिलो”, “हेर्नमा सहज” लगायतका कुराहरू हुन्।

आईटी सिस्टमको “लजिक” के हो?

तथापि, यदि आईटी सिस्टम “डिस्प्ले”मात्र भएको भए, त्यसले कुनै “गति” वा “परिवर्तन” लिन सक्दैन, केवल “डिस्प्ले” मात्र हुन्छ। प्रयोगकर्ताबाटको इनपुट स्वीकार गर्ने र आउटपुट प्रदर्शन गर्ने कार्य “डिस्प्ले”मा हुन्छ, तर यस प्रक्रियामा “गणना प्रक्रिया” हुन्छ।

यस्ता प्रयोगकर्ताको आँखाबाट देख्न नसकिने, अर्थात् “सिस्टमको पछाडिको भाग”ले जटिल गणना र नियन्त्रण गर्दछ। डिस्प्ले तर्फबाट डाटा खोज्ने, डाटा परिवर्तन गर्ने, थप्ने, हटाउने जस्ता कार्यहरू पूर्वनिर्मित डाटाबेसको पछाडि हुन्छ। डाटाबेसको जानकारीमा गरिने विभिन्न प्रक्रियाहरू सामान्यतया SQL भनिने कम्प्युटर भाषामा गरिन्छ।

डिस्प्ले तर्फ राखिएका बटनहरूलाई ट्रिगरको रूपमा प्रयोग गरी, आवश्यक SQL स्टेटमेन्टको कार्यान्वयनसम्मको प्रक्रिया बनाउने कुरा, यसले गति र परिवर्तन भएको सिस्टमको सम्पूर्ण रूप तयार पार्छ।

यसैगरी, “डिस्प्ले”बाट देख्न नसकिने विभिन्न लजिकहरूको निर्माणसँग सम्बन्धित कुरा “ब्याकएन्ड” भनेर पनि चिनिन्छ।

सिस्टमको कुरा गर्दा, स्क्रिनको ‘दृश्य’ मात्रैमा ध्यान केन्द्रित गर्नु जोखिमपूर्ण हुन सक्छ


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

जापानमा प्रयोगकर्ता र विक्रेताबीचको चासोका बिन्दुहरू फरक हुँदा जोखिम उत्पन्न हुन्छ

उदाहरणका लागि, IT प्रणालीको कुरा गर्दा ‘स्क्रिन’को केन्द्रमा रहने प्रयोगकर्ताहरू भित्री संरचनाको जटिलताप्रति उदासीन हुन सक्छन्। यसैले, सतहमा हेर्दा ‘सानो फिचर थप्ने’ वा ‘सामान्य स्पेसिफिकेसन परिवर्तन’ जस्ता कुराहरूले कति धेरै प्रक्रियाहरूमा प्रभाव पार्न सक्छ भन्ने कुरा बुझ्न सकिन्न। उदाहरणका रूपमा, तलको लेखमा नयाँ प्रणालीको विकासको परियोजनामा जडित भई हाल चलिरहेको पुरानो प्रणालीको हटाउने क्रममा उत्पन्न हुन सक्ने जापानी कानूनी समस्याहरूको विवरण दिइएको छ।

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

यहाँ, पुरानो प्रणालीको हटाइसँगै नयाँ प्रणालीमा डाटा सार्ने क्रममा अक्सर समस्या उत्पन्न हुने कुरा व्याख्या गरिएको छ। अर्थात्, सतहबाट हेर्दा कल्पना गर्न नसकिने गरी भित्री गणना र नियन्त्रणको प्रणाली जटिल र जडान गरिएको हुन सक्छ, जुन प्रयोगकर्ताका लागि अनपेक्षित समस्याको मूल बन्न सक्छ। यसैगरी, ‘प्रणाली बनाउने विक्रेताको मनोभावना’ नबुझिएको कारणले पछि परिवर्तनहरू सानो-सानोमा आउने जस्ता परिस्थितिहरू पनि उत्पन्न हुन सक्छन्।

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

यस्ता परिस्थितिहरूमा, पछि विशेषताहरूको परिवर्तन वा थप्ने कार्य आदेशित हुने अवस्थालाई ध्यानमा राख्दै, पुरस्कारको पछिल्लो बढोत्तरी सम्भव छ कि भन्ने कुरा पनि कहिलेकाहीँ गम्भीर समस्या बन्न सक्छ।

https://monolith.law/corporate/increase-of-estimate[ja]

प्रयोगकर्ताहरू अन्तर्निहित ‘लोजिक’ प्रति उदासीन हुँदा जोखिम बढ्दछ

यसका साथै, प्रयोगकर्ताहरूले देख्न नसक्ने भागहरूमा समस्या देखा पर्दा यसले ठूलो घटनामा परिणत हुन सक्छ। यस्ता उदाहरणहरू तल छन्।

रखरखाव र सुरक्षा सम्बन्धी समस्याहरूको उत्पत्ति हुन सक्ने खतरा

थप कार्यक्षमता समावेश गर्न नसक्ने, प्रयोग गर्दा धीरे धीरे सिस्टम भारी हुँदै जाने र अन्ततः काम नगर्ने अवस्था यसमा पर्दछ।

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

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

यस लेखको मुख्य विषय फ्रेमवर्क र लाइब्रेरी प्रयोगको साथ जोडिएका जोखिमहरू हुन्, तर प्रकाशित न्यायिक उदाहरणहरू SQL इन्जेक्शन प्रयोग गरी गरिएको आक्रमणका मामलाहरू हुन्।

सञ्चालन गर्ने व्यक्तिहरूको काममा गभर्नेन्स नपुग्ने खतरा

IT सिस्टमका प्रयोगकर्ताहरू अन्तर्निहित ‘लोजिक’ प्रति उदासीन रहँदा, IT सिस्टम सञ्चालन गर्ने व्यक्तिहरूको काममा गभर्नेन्स पुग्न कठिन हुन्छ। यस सम्बन्धमा तलको लेखमा ‘सञ्चालन गर्ने व्यक्तिको गल्तीले गर्दा डाटा हराउने’ विषयमा डाटाबेस सम्बन्धी कामको महत्वलाई विस्तृत रूपमा व्याख्या गरिएको छ।

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

सतहमा सही रूपमा काम गरिरहेको देखिए पनि, लोजिक गलत हुने खतरा

सिस्टमको कुरा केवल ‘स्क्रिन’मा सीमित नरहेकोले, सतहमा सही रूपमा काम गरिरहेको सिस्टम पनि वास्तवमा ‘लोजिक’ गलत हुन सक्छ। यो दैनिक मूल काममा स्पष्ट हुन नसके पनि, ‘छ महिनामा एक पटक’, ‘वार्षिक रूपमा’ जस्ता अनियमित कामहरूमा अकस्मात पत्ता लाग्न सक्छ।

यस्ता अवस्थामा, ‘एक पटक डेलिभरी पूरा भएपछि, पछि त्रुटि पत्ता लागेको मामला’को रूपमा, कानूनी रूपमा (ऋण अनुपालन भन्दा) दोष जिम्मेवारीको समस्या बन्छ।

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

यदि डेलिभरी पछि कुनै समस्या पत्ता लागेमा उपायका लागि तलको लेखमा प्रक्रियाको विस्तृत विवरण छ।

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

सारांश

सिस्टम विकास र कानूनी मामलाहरूमा व्यवस्थित बुझाइ

सिस्टम विकाससँग सम्बन्धित कानूनी समस्याहरूमा, कानूनी विषयहरूको पहिचान गर्ने प्रक्रियामा, IT सिस्टमका घटकहरूमा कुन भागमा समस्या उत्पन्न भएको छ भन्ने कुरा बुझ्नु पनि महत्त्वपूर्ण छ। कानूनी समस्याहरू मात्र होइन, IT सिस्टमका समस्याहरू पनि, सिस्टम विकास परियोजनामा उत्पन्न हुने विवादहरूमा समग्र दृष्टिकोण गुमाउनु हुँदैन र विभिन्न क्षेत्रहरू बीचको सहकार्यमा ध्यान केन्द्रित गर्नु विशेष रूपमा महत्त्वपूर्ण मानिन्छ।

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

माथि फर्कनुहोस्