सॉफ़्टवेयर रोट
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
(Learn how and when to remove this template message)
|
सॉफ़्टवेयर रोट (बिट रोट, कोड रोट, सॉफ़्टवेयर कटाव, सॉफ़्टवेयर क्षय, या सॉफ्टवेयर एन्ट्रापी) या तो समय के साथ सॉफ़्टवेयर गुणवत्ता की धीमी गिरावट है या इसकी कम प्रतिक्रियात्मकता है जो अंततः सॉफ़्टवेयर को दोषपूर्ण, अनुपयोगी या अपग्रेड की आवश्यकता में ले जाएगी। यह एक भौतिक घटना नहीं है: सॉफ्टवेयर वास्तव में क्षय नहीं करता है, बल्कि बदलते परिवेश के संबंध में उत्तरदायी और अद्यतन होने की कमी से ग्रस्त है जिसमें यह रहता है।
शब्दजाल फ़ाइल, हैकर विद्या का एक संग्रह, "बिट रोट" को समय के साथ एक सॉफ्टवेयर प्रोग्राम के क्षरण के लिए एक मजाकिया व्याख्या के रूप में परिभाषित करता है, भले ही "कुछ भी नहीं बदला हो"; इसके पीछे का विचार लगभग ऐसा है जैसे प्रोग्राम बनाने वाले बिट्स रेडियोधर्मी क्षय के अधीन थे।[1]
कारण
सॉफ़्टवेयर रोट के लिए कई कारक जिम्मेदार हैं, जिसमें पर्यावरण में परिवर्तन सम्मिलित हैं जिसमें सॉफ़्टवेयर स्वयं सॉफ़्टवेयर के कुछ हिस्सों के बीच संगतता में गिरावट और अप्रयुक्त या शायद ही कभी उपयोग किए गए कोड में बग (सॉफ्टवेयर) की उपस्थिति को संचालित करता है।
पर्यावरण परिवर्तन
जब कार्यक्रम के वातावरण में परिवर्तन होते हैं, विशेष रूप से परिवर्तन जो कार्यक्रम के डिजाइनर ने अनुमान नहीं लगाया था, तो सॉफ्टवेयर अब मूल रूप से काम नहीं कर सकता है। उदाहरण के लिए, कई शुरुआती वीडियो गेम डिजाइनरों ने अपने गेम में सीपीयू घड़ी की गति को टाइमर के रूप में इस्तेमाल किया था।[2] हालाँकि, नए CPU घड़ियाँ तेज़ थीं, इसलिए गेमप्ले की गति उसी के अनुसार बढ़ी, जिससे समय के साथ खेल कम उपयोगी हो गए।
एक बार योग्यता
पर्यावरण में ऐसे परिवर्तन हैं जो प्रोग्राम के डिज़ाइनर से संबंधित नहीं हैं, बल्कि इसके उपयोगकर्ता हैं। प्रारंभ में, एक उपयोगकर्ता सिस्टम को कार्य क्रम में ला सकता है, और यह निश्चित समय के लिए त्रुटिपूर्ण रूप से काम कर सकता है। लेकिन, जब सिस्टम सही ढंग से काम करना बंद कर देता है, या उपयोगकर्ता कॉन्फ़िगरेशन नियंत्रणों तक पहुंच बनाना चाहते हैं, तो वे अलग-अलग संदर्भ और अनुपलब्ध जानकारी (पासवर्ड खो जाने, गुम निर्देश, या बस एक कठिन-से-प्रबंधित उपयोगकर्ता) के कारण उस प्रारंभिक चरण को दोहरा नहीं सकते हैं। इंटरफ़ेस जिसे पहले परीक्षण और त्रुटि द्वारा कॉन्फ़िगर किया गया था)। सूचना वास्तुकार जोनास सॉडरस्ट्रॉम ने इस अवधारणा को वन्सेबिलिटी नाम दिया है[3] और इसे "तकनीकी प्रणाली में गुणवत्ता के रूप में परिभाषित किया है जो उपयोगकर्ता को सिस्टम को पुनर्स्थापित करने से रोकता है, एक बार यह विफल हो जाता है"।
अप्रयुक्त कोड
कोड के प्रायः उपयोग किए जाने वाले भाग, जैसे दस्तावेज़ फ़िल्टर या अन्य प्रोग्राम द्वारा उपयोग किए जाने के लिए डिज़ाइन किए गए इंटरफ़ेस में बग हो सकते हैं जो किसी का ध्यान नहीं जाते हैं। उपयोगकर्ता आवश्यकताओं और अन्य बाहरी कारकों में परिवर्तन के साथ, इस कोड को बाद में निष्पादित किया जा सकता है, जिससे बग उजागर हो जाते हैं और सॉफ़्टवेयर कम कार्यात्मक दिखाई देता है।
शायद ही कभी अपडेट किया गया कोड
सॉफ्टवेयर और सिस्टम के सामान्य रखरखाव से भी सॉफ्टवेयर सड़ सकता है। विशेष रूप से, जब एक प्रोग्राम में कई भाग होते हैं जो एक दूसरे से हाथ की दूरी पर कार्य करते हैं, तो यह विचार करने में विफल रहता है कि कैसे एक भाग में परिवर्तन जो दूसरों को प्रभावित करता है, बग का परिचय दे सकता है।
कुछ मामलों में, यह उन पुस्तकालयों का रूप ले सकता है जो सॉफ़्टवेयर का उपयोग इस तरह से बदलते हैं जो सॉफ़्टवेयर पर प्रतिकूल प्रभाव डालते हैं। यदि किसी लाइब्रेरी का पुराना संस्करण जो पहले सॉफ़्टवेयर के साथ काम करता था, अन्य सॉफ़्टवेयर के साथ संघर्ष या पुराने संस्करण में पाए गए सुरक्षा दोषों के कारण अब उपयोग नहीं किया जा सकता है, तो प्रोग्राम के लिए आवश्यक लाइब्रेरी का व्यवहार्य संस्करण अब नहीं हो सकता है उपयोग।
ऑनलाइन कनेक्टिविटी
आधुनिक व्यावसायिक सॉफ़्टवेयर प्रायः लाइसेंस सत्यापन और जानकारी तक पहुँचने के लिए एक ऑनलाइन सर्वर से जुड़ते हैं। यदि सॉफ़्टवेयर को सशक्त करने वाली ऑनलाइन सेवा बंद कर दी जाती है, तो यह काम करना बंद कर सकता है।[4][5]
2010 के अंत से अधिकांश वेबसाइटें सुरक्षित एचटीटीपीएस कनेक्शन का उपयोग करती हैं। हालाँकि इसके लिए एन्क्रिप्शन कुंजी की आवश्यकता होती है जिसे रूट प्रमाण पत्र कहा जाता है जिसकी समाप्ति तिथि होती है। प्रमाणपत्रों के समाप्त होने के बाद डिवाइस अधिकांश वेबसाइटों से कनेक्टिविटी खो देता है जब तक कि कुंजियों को लगातार अपडेट नहीं किया जाता है।[6]
वर्गीकरण
सॉफ़्टवेयर सड़ांध को आमतौर पर निष्क्रिय सड़ांध या सक्रिय सड़ांध के रूप में वर्गीकृत किया जाता है।
सुप्त सड़ांध
सॉफ़्टवेयर जो वर्तमान में उपयोग नहीं किया जा रहा है धीरे-धीरे अनुपयोगी हो जाता है क्योंकि शेष एप्लिकेशन बदल जाता है। उपयोगकर्ता की आवश्यकताओं में परिवर्तन और सॉफ्टवेयर वातावरण भी गिरावट में योगदान करते हैं।
सक्रिय सड़ांध
सॉफ़्टवेयर जिसे लगातार संशोधित किया जा रहा है, समय के साथ अपनी अखंडता खो सकता है यदि उचित शमन प्रक्रियाओं को लगातार लागू नहीं किया जाता है। हालाँकि, नई आवश्यकताओं को पूरा करने और बग को ठीक करने के लिए बहुत से सॉफ़्टवेयर में निरंतर परिवर्तन की आवश्यकता होती है, और हर बार परिवर्तन किए जाने पर सॉफ़्टवेयर को फिर से इंजीनियरिंग करना शायद ही व्यावहारिक होता है। यह कार्यक्रम के लिए अनिवार्य रूप से एक विकास प्रक्रिया बनाता है, जिससे यह मूल इंजीनियर डिजाइन से हट जाता है। इसके परिणामस्वरूप और एक बदलते परिवेश में, मूल डिजाइनरों द्वारा की गई धारणाएं अमान्य हो सकती हैं, जिससे बग का परिचय हो सकता है।
व्यवहार में, दस्तावेज़ों को अद्यतन करने पर नई सुविधाओं को जोड़ने को प्राथमिकता दी जा सकती है; दस्तावेज़ीकरण के बिना, हालांकि, कार्यक्रम के कुछ हिस्सों से संबंधित विशिष्ट ज्ञान खो जाना संभव है। कुछ हद तक, कोडिंग सम्मेलनों के लिए सर्वोत्तम सम्मिलित प्रथाओं का पालन करके इसे कम किया जा सकता है।
एक बार जब कोई एप्लिकेशन अपने व्यावसायिक जीवन के अंत के करीब होता है तो सक्रिय सॉफ़्टवेयर रोट धीमा हो जाता है और आगे का विकास बंद हो जाता है। उपयोगकर्ता प्रायः किसी भी शेष सॉफ्टवेयर बग के आसपास काम करना सीखते हैं, और सॉफ़्टवेयर का व्यवहार सुसंगत हो जाता है क्योंकि कुछ भी नहीं बदल रहा है।
उदाहरण
एआई कार्यक्रम उदाहरण
एआई अनुसंधान के शुरुआती दिनों से कई मौलिक कार्यक्रम अपूरणीय सॉफ्टवेयर सड़ांध से पीड़ित हैं। उदाहरण के लिए, मूल SHRDLU प्रोग्राम (प्रारंभिक प्राकृतिक भाषा समझ कार्यक्रम) किसी भी आधुनिक दिन के कंप्यूटर या कंप्यूटर सिम्युलेटर पर नहीं चलाया जा सकता है, क्योंकि यह उन दिनों के दौरान विकसित किया गया था जब लिस्प और PLANNER अभी भी विकास के चरण में थे, और इस प्रकार यह गैर-मानक का उपयोग करता है। मैक्रोज़ और सॉफ़्टवेयर लाइब्रेरी जो अब मौजूद नहीं हैं।
ऑनलाइन मंच उदाहरण
मान लीजिए कि एक व्यवस्थापक खुला स्रोत सॉफ्टवेयर फ़ोरम सॉफ़्टवेयर का उपयोग करके एक फ़ोरम बनाता है, और फिर नई सुविधाओं और विकल्पों को जोड़कर इसे भारी रूप से संशोधित करता है। इस प्रक्रिया के लिए सम्मिलित कोड में व्यापक संशोधन और उस सॉफ़्टवेयर की मूल कार्यक्षमता से विचलन की आवश्यकता होती है।
यहाँ से, ऐसे कई तरीके हैं जिनसे सॉफ़्टवेयर रोट सिस्टम को प्रभावित कर सकता है:
- व्यवस्थापक गलती से ऐसे परिवर्तन कर सकता है जो एक दूसरे या मूल सॉफ़्टवेयर के साथ संघर्ष करते हैं, जिससे फ़ोरम अप्रत्याशित रूप से व्यवहार करता है या पूरी तरह से टूट जाता है। यह उन्हें बहुत खराब स्थिति में छोड़ देता है: चूंकि वे मूल कोड से बहुत अधिक विचलित हो गए हैं, तकनीकी सहायता और फोरम को पुनर्जीवित करने में सहायता प्राप्त करना मुश्किल होगा।
- मूल फ़ोरम स्रोत कोड में एक सुरक्षा छेद खोजा जा सकता है, जिसके लिए सुरक्षा पैच की आवश्यकता होती है। हालाँकि, क्योंकि व्यवस्थापक ने कोड को इतने व्यापक रूप से संशोधित किया है, पैच सीधे उनके कोड पर लागू नहीं हो सकता है, जिसके लिए व्यवस्थापक को अपडेट को प्रभावी ढंग से फिर से लिखने की आवश्यकता होती है।
- संशोधन करने वाला व्यवस्थापक अपना पद खाली कर सकता है, जिससे नए व्यवस्थापक के पास एक पेचीदा और अत्यधिक संशोधित फ़ोरम रह जाता है जिसमें पूर्ण दस्तावेज़ीकरण का अभाव होता है। संशोधनों को पूरी तरह से समझे बिना, नए व्यवस्थापक के लिए विरोधों और बगों को सम्मिलित किए बिना परिवर्तन करना कठिन है। इसके अलावा, मूल प्रणाली का प्रलेखन अब उपलब्ध नहीं हो सकता है, या इससे भी बदतर, कार्यात्मक आवश्यकताओं में सूक्ष्म अंतर के कारण भ्रामक हो सकता है।
रिफैक्टरिंग
कोड रीफैक्टरिंग सड़न की समस्या को दूर करने का एक साधन है। इसे इसके बाहरी व्यवहार को प्रभावित किए बिना इसकी संरचना में सुधार के लिए सम्मिलित कोड को फिर से लिखने की प्रक्रिया के रूप में वर्णित किया गया है।[7] इसमें मृत कोड उन्मूलन को हटाना और उन अनुभागों को फिर से लिखना सम्मिलित है जिन्हें व्यापक रूप से संशोधित किया गया है और जो अब कुशलता से काम नहीं करते हैं। सॉफ़्टवेयर के बाहरी व्यवहार को बदलने के लिए सावधानी नहीं बरती जानी चाहिए, क्योंकि इससे असंगतताएँ आ सकती हैं और इस तरह स्वयं सॉफ़्टवेयर सड़ने में योगदान होता है।
यह भी देखें
- कोड गंध
- निर्भरता नरक
- पीढ़ी का नुकसान
- सॉफ्टवेयर ब्लोट
- सॉफ्टवेयर भंगुरता
- सॉफ्टवेयर एन्ट्रापी
- SOLID
संदर्भ
- ↑ Raymond, Eric. "Bit rot". The Jargon File. Retrieved 3 March 2013.
- ↑ Inc, Ziff Davis (1992-01-28). PC Mag (in English). Ziff Davis, Inc. p. 286.
{{cite book}}:|last=has generic name (help) - ↑ Jonas Söderström. "Onceability: The consequence of technology rot".
- ↑ Amadeo, Ron (31 October 2016). "The (updated) history of Android". Ars Technica (in English). Retrieved 31 October 2021.
- ↑ "Adobe CS2 is Now Available for Free, Sort Of". Mobile Magazine. 2013-01-14. Archived from the original on 2013-01-18. Retrieved 2013-01-20.
- ↑ https://www.tomsguide.com/news/android-cert-mess-averted
- ↑ Fowler, Martin (October 11, 2007). "What Is Refactoring". Retrieved 2007-11-22.
