सॉफ्टवेयर बग
| Part of a series on |
| Software development |
|---|
सॉफ़्टवेयर बग कंप्यूटर सॉफ्टवेयर के डिज़ाइन, विकास या संचालन में एक त्रुटि, दोष या दोष (तकनीक) है जिसके कारण यह गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या अनपेक्षित विधि से व्यवहार करता है। बग को खोजने और सुधारने की प्रक्रिया को डिबगिंग कहा जाता है और अधिकांशतः बग को इंगित करने के लिए औपचारिक तकनीकों या उपकरणों का उपयोग किया जाता है। 1950 के दशक के बाद से कुछ कंप्यूटर सिस्टम संचालन के समय विभिन्न कंप्यूटर बगों को रोकने, पहचानने या स्वत। ठीक करने के लिए डिज़ाइन किए गए हैं।
सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के सॉफ़्टवेयर डिजाइन की योजना बना सकते हैं, इसके सोर्स कोड लिख सकते हैं, और ऑपरेटिंग सिस्टम या लाइब्रेरी (कम्प्यूटिंग) जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः बग के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को क्रैश (कंप्यूटिंग), कंप्यूटर को फ्रीज (कंप्यूटिंग) करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, विशेषाधिकार वृद्धि के लिए पहुँच नियंत्रण (एक्सेस कंट्रोल) को बायपास करने के लिए ब्लैक कैप हैकिंग को सक्षम कर सकते हैं।[1]
कुछ सॉफ़्टवेयर बग्स को आपदाओं से जोड़ा गया है। 1980 के दशक में थेरेक-25 विकिरण उपचार मशीन को नियंत्रित करने वाले कोड में वॉर्म्स सीधे मरीजों की मौत के लिए जिम्मेदार थे। 1996 में, ऑन-बोर्ड मार्गदर्शन कंप्यूटर प्रोग्राम में बग के कारण यूरोपीय अंतरिक्ष एजेंसी के US$1 बिलियन प्रोटोटाइप एरियन उड़ान V88 लॉन्च के एक मिनट से भी कम समय बाद।[2] 1994 में, 1994 स्कॉटलैंड आरएएफ चिनूक दुर्घटना दुर्घटना, 29 की मौत; शुरुआत में इसे पायलट त्रुटि के लिए दोषी ठहराया गया था, लेकिन बाद में माना गया कि यह एफएडीईसी (FADEC) इंजन-कंट्रोल कंप्यूटर में एक सॉफ्टवेयर बग के कारण हुआ है।[3] बग सॉफ्टवेयर ने 21वीं सदी के आरंभिक ब्रिटिश डाकघर घोटाला का कारण बना, ब्रिटिश कानूनी इतिहास में न्याय का सबसे व्यापक गर्भपात।[4]
2002 में, अमेरिकी वाणिज्य विभाग के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा शुरू किए गए अध्ययन ने निष्कर्ष निकाला कि सॉफ्टवेयर बग, या त्रुटियां, इतनी प्रचलित और इतनी हानिकारक हैं कि वे अमेरिकी अर्थव्यवस्था को अनुमानित रूप से सकल घरेलू उत्पाद के लिए $59 बिलियन वार्षिक, या लगभग 0.6 प्रतिशत खर्च करते हैं।[5]
इतिहास
मध्य अंग्रेजी शब्द wikt।bugge#Noun शब्दों के लिए आधार है wikt।bugbear#Noun और wikt।bug-a-boo#Noun एक राक्षस के लिए प्रयुक्त शब्दों के रूप में।[6]
दोषों का वर्णन करने के लिए बग शब्द 1870 के दशक से इंजीनियरिंग शब्दजाल का एक भाग रहा है[7] और इलेक्ट्रॉनिक्स और कंप्यूटरों की भविष्यवाणी करता है; यह मूल रूप से यांत्रिक खराबी का वर्णन करने के लिए हार्डवेयर इंजीनियरिंग में उपयोग किया गया हो सकता है। उदाहरण के लिए, थॉमस एडीसन ने 1878 में एक सहयोगी को लिखे पत्र में लिखा था।[8]
बाफल बॉल, पहला मैकेनिकल पिनबॉल गेम, 1931 में वॉर्म्स से मुक्त होने के रूप में विज्ञापित किया गया था।[9] द्वितीय विश्व युद्ध के समय सैन्य गियर के साथ समस्याओं को बग (या ग्लिट्स) कहा जाता था।[10] 1942 में प्रकाशित एक पुस्तक में, लुईस डिकिंसन रिच ने एक संचालित बर्फ काटने वाली मशीन के बारे में बात करते हुए कहा, बर्फ काटने को तब तक के लिए निलंबित कर दिया गया था जब तक कि निर्माता को अपने प्रिय से वॉर्म्स निकालने के लिए नहीं लाया जा सकता था।[11] कहानी का एक विशिष्ट संस्करण है।
जब बग पाया गया तो हूपर सम्मलित नहीं था, लेकिन यह उसकी पसंदीदा कहानियों में से एक बन गई।[12] लॉग बुक में तारीख 9 सितंबर, 1947 थी।[13][14][15] जिन ऑपरेटरों ने इसे पाया, उनमें विलियम बिल बर्क, बाद में नेवल सरफेस वारफेयर सेंटर डहलग्रेन डिवीजन, डहलग्रेन, वर्जीनिया, सम्मलित थे।[16] इंजीनियरिंग की शब्दावली से परिचित थे और मनोरंजक विधि से कीट को इस संकेतन के साथ रखा कि बग का पहला वास्तविक स्थिति पाया जा रही है। संलग्न कीट के साथ पूर्ण यह लॉग बुक, अमेरिकी इतिहास के स्मिथसोनियन राष्ट्रीय संग्रहालय के संग्रह का भाग है।[14]
संबंधित शब्द डिबग भी कंप्यूटिंग में इसके उपयोग से पहले का प्रतीत होता है। ऑक्सफोर्ड इंग्लिश डिक्शनरी'शब्द की व्युत्पत्ति में विमान इंजन के संदर्भ में 1945 से एक प्रमाणन सम्मलित है।[17]
यह ऐसी अवधारणा है कि सॉफ्टवेयर में त्रुटियां हो सकती हैं, विश्लेषणात्मक इंजन पर एडा बायरन के नोट्स से मिलती हैं। एडा लवलेस के 1843 नोट्स एनालिटिकल इंजन पर, जिसमें वह चार्ल्स बैबेज के एनालिटिकल इंजन के गलत होने के लिए प्रोग्राम कार्ड की संभावना की बात करती हैं।
विश्लेषणात्मक इंजन को आवश्यक ऑपरेटिव डेटा प्रस्तुत करने के लिए एक विश्लेषण प्रक्रिया समान रूप से निष्पादित की जानी चाहिए; और इसमें त्रुटि का संभावित स्रोत भी हो सकता है। यह माना जाता है कि वास्तविक तंत्र अपनी प्रक्रियाओं में त्रुटिहीन है, कार्ड इसे गलत आदेश दे सकते हैं।
सिस्टम रिपोर्ट में वायरस
मुक्त प्रौद्योगिकी संस्थान, समूह, न्यू अमेरिका द्वारा चलाया जाता है,[18] अगस्त 2016 में एक रिपोर्ट बग्स इन द सिस्टम जारी की जिसमें कहा गया था कि अमेरिकी नीति निर्माताओं को सॉफ्टवेयर बगों की पहचान करने और उन्हें दूर करने में शोधकर्ताओं की मदद करने के लिए सुधार करना चाहिए। रिपोर्ट में सॉफ्टवेयर भेद्यता खोज और प्रकटीकरण के क्षेत्र में सुधार की आवश्यकता पर प्रकाश डाला गया है।[19] रिपोर्ट के लेखकों में से एक ने कहा कि कांग्रेस ने साइबर सॉफ़्टवेयर भेद्यता को दूर करने के लिए पर्याप्त नहीं किया है, भले ही कांग्रेस ने साइबर सुरक्षा के बड़े विवाद का मुकाबला करने के लिए कई बिल पारित किए हैं।[19]
सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो साधारणतयः सॉफ़्टवेयर की कमियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है।[19]
कंप्यूटर फ्रॉड एंड एब्यूज एक्ट, डिजिटल मिलेनियम कॉपीराइट एक्ट और इलेक्ट्रॉनिक कम्युनिकेशंस प्राइवेसी एक्ट उन कार्रवाइयों के लिए अपराधीकरण और नागरिक दंड बनाते हैं, जो सुरक्षा शोधकर्ता नियमित रूप से वैध सुरक्षा अनुसंधान करते समय संलग्न करते हैं, रिपोर्ट में कहा गया है। 1970 के दशक के बाद से गैरी किल्डाल ने कुछ विनोदी ढंग से ब्लंडर शब्द का उपयोग करने का सुझाव दिया।[20][21] जो इसमें सम्मलित है।
टंकण त्रुटियाँ
बग साधारणतयः तब दिखाई देते हैं जब प्रोग्रामर एक तार्किक त्रुटि करता है। प्रोग्रामिंग शैली और रक्षात्मक प्रोग्रामिंग में विभिन्न नवाचारों को इन बगों की संभावना कम करने, या स्पॉट करने में आसान बनाने के लिए डिज़ाइन किया गया है। कुछ टाइपो, विशेष रूप से प्रतीकों या तार्किक/ऑपरेटर (गणित) के, प्रोग्राम को गलत विधि से संचालित करने की अनुमति देते हैं, जबकि अन्य जैसे लापता प्रतीक या गलत वर्तनी वाले नाम प्रोग्राम को संचालन से रोक सकते हैं। सोर्स कोड संकलित होने पर संकलित भाषाएँ कुछ टाइपो प्रकट कर सकती हैं।
विकास के विधि
कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। सॉफ्टवेयर इंजीनियरिंग (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई विधियों को लागू करती है। उदाहरण के लिए, औपचारिक कार्यक्रम विनिर्देश कार्यक्रमों के सटीक व्यवहार को बताते हैं जिससे कि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण।
इकाई का परीक्षण में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है।
परीक्षण-संचालित विकास में इकाई परीक्षण कोड से पहले लिखे जाते हैं और कोड को तब तक पूर्ण नहीं माना जाता जब तक कि सभी परीक्षण सफलतापूर्वक पूर्ण नहीं हो जाते।
चुस्त सॉफ्टवेयर विकास में अपेक्षाकृत छोटे बदलावों के साथ लगातार सॉफ्टवेयर रिलीज सम्मलित होते हैं। उपयोगकर्ता प्रतिक्रिया से दोष प्रकट होते हैं।
ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय ओपन सोर्स सॉफ्टवेयर में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं।[22] चूंकि, यह दावा विवादित रहा है। कंप्यूटर सुरक्षा विशेषज्ञ इलियास लेवी ने लिखा है कि जटिल, कम समझ में आने वाले और बिना दस्तावेज वाले सोर्स कोड में कमजोरियों को छिपाना आसान है, क्योंकि भले ही लोग कोड की समीक्षा कर रहे हों, इसका मतलब यह नहीं है कि वे योग्य हैं ऐसा करने के लिए।[23] ओपन-सोर्स सॉफ़्टवेयर बग का एक उदाहरण डेबियन 2008 ओपनएसएसएल भेद्यता थी।