सॉफ्टवेयर बग: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के [[सॉफ़्टवेयर वास्तुशिल्प|सॉफ़्टवेयर डिजाइन]] की योजना बना सकते हैं, इसके स्रोत कोड लिख सकते हैं, और [[ऑपरेटिंग सिस्टम]] या [[पुस्तकालय (कम्प्यूटिंग)|लाइब्रेरी (कम्प्यूटिंग)]] जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः ''बग'' के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को [[क्रैश (कंप्यूटिंग)]], कंप्यूटर को [[फ्रीज (कंप्यूटिंग)]] करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, [[विशेषाधिकार वृद्धि]] के लिए [[पहुँच नियंत्रण|पहुँच नियंत्रण (एक्सेस कंट्रोल)]] को बायपास करने के लिए [[काली टोपी हैकिंग|ब्लैक कैप हैकिंग]] को सक्षम कर सकते हैं।<ref>{{Cite journal|last1=Mittal|first1=Varun|last2=Aditya|first2=Shivam|date=2015-01-01|title=बग फिक्सिंग के क्षेत्र में हालिया विकास|journal=Procedia Computer Science|series=International Conference on Computer, Communication and Convergence (ICCC 2015)|language=en|volume=48|pages=288–297|doi=10.1016/j.procs.2015.04.184|issn=1877-0509|doi-access=free}}</ref> | सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के [[सॉफ़्टवेयर वास्तुशिल्प|सॉफ़्टवेयर डिजाइन]] की योजना बना सकते हैं, इसके स्रोत कोड लिख सकते हैं, और [[ऑपरेटिंग सिस्टम]] या [[पुस्तकालय (कम्प्यूटिंग)|लाइब्रेरी (कम्प्यूटिंग)]] जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः ''बग'' के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को [[क्रैश (कंप्यूटिंग)]], कंप्यूटर को [[फ्रीज (कंप्यूटिंग)]] करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, [[विशेषाधिकार वृद्धि]] के लिए [[पहुँच नियंत्रण|पहुँच नियंत्रण (एक्सेस कंट्रोल)]] को बायपास करने के लिए [[काली टोपी हैकिंग|ब्लैक कैप हैकिंग]] को सक्षम कर सकते हैं।<ref>{{Cite journal|last1=Mittal|first1=Varun|last2=Aditya|first2=Shivam|date=2015-01-01|title=बग फिक्सिंग के क्षेत्र में हालिया विकास|journal=Procedia Computer Science|series=International Conference on Computer, Communication and Convergence (ICCC 2015)|language=en|volume=48|pages=288–297|doi=10.1016/j.procs.2015.04.184|issn=1877-0509|doi-access=free}}</ref> | ||
कुछ सॉफ़्टवेयर बग्स को आपदाओं से जोड़ा गया है। 1980 के दशक में [[Therac -25]] [[विकिरण उपचार]] मशीन को नियंत्रित करने वाले कोड में कीड़े सीधे | कुछ सॉफ़्टवेयर बग्स को आपदाओं से जोड़ा गया है। 1980 के दशक में [[Therac -25|थेरेक-25]] [[विकिरण उपचार]] मशीन को नियंत्रित करने वाले कोड में कीड़े सीधे मरीजों की मौत के लिए जिम्मेदार थे। 1996 में, ऑन-बोर्ड मार्गदर्शन कंप्यूटर प्रोग्राम में बग के कारण [[यूरोपीय अंतरिक्ष एजेंसी]] के US$1 बिलियन प्रोटोटाइप [[एरियन उड़ान V88]] लॉन्च के एक मिनट से भी कम समय बाद।<ref>{{Cite web|title=एरियन 501 - पूछताछ बोर्ड की रिपोर्ट की प्रस्तुति|url=https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report|access-date=2022-01-29|website=www.esa.int|language=en}}</ref> 1994 में, [[1994 स्कॉटलैंड आरएएफ चिनूक दुर्घटना]] दुर्घटना, 29 की मौत; शुरुआत में इसे पायलट त्रुटि के लिए दोषी ठहराया गया था, लेकिन बाद में माना गया कि यह [[FADEC|एफएडीईसी (FADEC)]]|इंजन-कंट्रोल कंप्यूटर में एक सॉफ्टवेयर बग के कारण हुआ है।<ref>{{cite web |author= Prof. [[Simon Rogerson]] |url= http://www.ccsr.cse.dmu.ac.uk/resources/general/ethicol/Ecv12no2.html |title= चिनूक हेलीकाप्टर आपदा|publisher= Ccsr.cse.dmu.ac.uk |access-date= September 24, 2012 |url-status= dead |archive-url= https://web.archive.org/web/20120717021641/http://www.ccsr.cse.dmu.ac.uk/resources/general/ethicol/Ecv12no2.html |archive-date= July 17, 2012 |df= mdy-all }}</ref> बग सॉफ्टवेयर ने 21वीं सदी के आरंभिक [[ब्रिटिश डाकघर घोटाला]] का कारण बना, ब्रिटिश कानूनी इतिहास में न्याय का सबसे व्यापक गर्भपात।<ref name="beeb182">{{Cite news |title=पोस्ट ऑफिस स्कैंडल ने बर्बाद की जिंदगी, जांच में सुनवाई|author=<!--not stated--> |work=BBC News |date=14 February 2022 |url= https://www.bbc.co.uk/news/business-60374182}}</ref> | ||
2002 में, अमेरिकी वाणिज्य विभाग के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा शुरू किए गए | 2002 में, अमेरिकी वाणिज्य विभाग के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा शुरू किए गए अध्ययन ने निष्कर्ष निकाला कि सॉफ्टवेयर बग, या त्रुटियां, इतनी प्रचलित और इतनी हानिकारक हैं कि वे अमेरिकी अर्थव्यवस्था को अनुमानित रूप से सकल घरेलू उत्पाद के लिए $59 बिलियन वार्षिक, या लगभग 0.6 प्रतिशत खर्च करते हैं।<ref>{{cite web|url=http://www.nist.gov/public_affairs/releases/n02-10.htm |title=सॉफ्टवेयर बग अमेरिकी अर्थव्यवस्था को महंगा पड़ा|date=June 10, 2009 |access-date=September 24, 2012 |url-status=unfit |archive-url=https://web.archive.org/web/20090610052743/http://www.nist.gov/public_affairs/releases/n02-10.htm |archive-date=June 10, 2009 }}</ref> | ||
== इतिहास == | == इतिहास == | ||
{{main|बग (इंजीनियरिंग)}} | {{main|बग (इंजीनियरिंग)}} | ||
| Line 34: | Line 34: | ||
=== सिस्टम रिपोर्ट में | === सिस्टम रिपोर्ट में वायरस === | ||
मुक्त प्रौद्योगिकी संस्थान, समूह, न्यू अमेरिका द्वारा चलाया जाता है,<ref name=":1">{{Cite web|url=https://na-production.s3.amazonaws.com/documents/Bugs-in-the-System-Final.pdf|title=सिस्टम में कीड़े|last1=Wilson|first1=Andi|last2=Schulman|first2=Ross|website=Open Policy Institute|access-date=August 22, 2016|last3=Bankston|first3=Kevin|last4=Herr|first4=Trey|url-status=live|archive-url=https://web.archive.org/web/20160921012606/https://na-production.s3.amazonaws.com/documents/Bugs-in-the-System-Final.pdf|archive-date=September 21, 2016}}</ref> अगस्त 2016 में एक रिपोर्ट बग्स इन द सिस्टम जारी की जिसमें कहा गया था कि अमेरिकी नीति निर्माताओं को सॉफ्टवेयर बगों की पहचान करने और उन्हें दूर करने में शोधकर्ताओं की मदद करने के लिए सुधार करना चाहिए। रिपोर्ट में सॉफ्टवेयर भेद्यता खोज और प्रकटीकरण के क्षेत्र में सुधार की आवश्यकता पर प्रकाश डाला गया है।<ref name=":0">{{Cite web|url=https://homelandprepnews.com/government/19481-cyber-reforms-needed-strengthen-software-bug-discovery-disclosure-new-america-report/|title=सॉफ्टवेयर बग खोज और प्रकटीकरण को मजबूत करने के लिए साइबर सुधारों की आवश्यकता: नई अमेरिका रिपोर्ट - होमलैंड तैयारी समाचार|last=Rozens|first=Tracy|date=August 12, 2016|language=en-US|access-date=August 23, 2016}}</ref> रिपोर्ट के लेखकों में से एक ने कहा कि कांग्रेस ने साइबर सॉफ़्टवेयर भेद्यता को दूर करने के लिए पर्याप्त नहीं किया है, भले ही कांग्रेस ने साइबर सुरक्षा के बड़े मुद्दे का मुकाबला करने के लिए कई बिल पारित किए हैं।<ref name=":0" /> | मुक्त प्रौद्योगिकी संस्थान, समूह, न्यू अमेरिका द्वारा चलाया जाता है,<ref name=":1">{{Cite web|url=https://na-production.s3.amazonaws.com/documents/Bugs-in-the-System-Final.pdf|title=सिस्टम में कीड़े|last1=Wilson|first1=Andi|last2=Schulman|first2=Ross|website=Open Policy Institute|access-date=August 22, 2016|last3=Bankston|first3=Kevin|last4=Herr|first4=Trey|url-status=live|archive-url=https://web.archive.org/web/20160921012606/https://na-production.s3.amazonaws.com/documents/Bugs-in-the-System-Final.pdf|archive-date=September 21, 2016}}</ref> अगस्त 2016 में एक रिपोर्ट बग्स इन द सिस्टम जारी की जिसमें कहा गया था कि अमेरिकी नीति निर्माताओं को सॉफ्टवेयर बगों की पहचान करने और उन्हें दूर करने में शोधकर्ताओं की मदद करने के लिए सुधार करना चाहिए। रिपोर्ट में सॉफ्टवेयर भेद्यता खोज और प्रकटीकरण के क्षेत्र में सुधार की आवश्यकता पर प्रकाश डाला गया है।<ref name=":0">{{Cite web|url=https://homelandprepnews.com/government/19481-cyber-reforms-needed-strengthen-software-bug-discovery-disclosure-new-america-report/|title=सॉफ्टवेयर बग खोज और प्रकटीकरण को मजबूत करने के लिए साइबर सुधारों की आवश्यकता: नई अमेरिका रिपोर्ट - होमलैंड तैयारी समाचार|last=Rozens|first=Tracy|date=August 12, 2016|language=en-US|access-date=August 23, 2016}}</ref> रिपोर्ट के लेखकों में से एक ने कहा कि कांग्रेस ने साइबर सॉफ़्टवेयर भेद्यता को दूर करने के लिए पर्याप्त नहीं किया है, भले ही कांग्रेस ने साइबर सुरक्षा के बड़े मुद्दे का मुकाबला करने के लिए कई बिल पारित किए हैं।<ref name=":0" /> | ||
सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो साधारणतयः सॉफ़्टवेयर की कमियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है।<ref name=":0" /> | सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो साधारणतयः सॉफ़्टवेयर की कमियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है।<ref name=":0" /><blockquote>कंप्यूटर फ्रॉड एंड एब्यूज एक्ट, डिजिटल मिलेनियम कॉपीराइट एक्ट और इलेक्ट्रॉनिक कम्युनिकेशंस प्राइवेसी एक्ट उन कार्रवाइयों के लिए अपराधीकरण और नागरिक दंड बनाते हैं, जो सुरक्षा शोधकर्ता नियमित रूप से वैध सुरक्षा अनुसंधान करते समय संलग्न करते हैं, रिपोर्ट में कहा गया है।<ref name=":0"><nowiki>}}</nowiki> | ||
< | |||
== शब्दावली == | == शब्दावली == | ||
| Line 52: | Line 50: | ||
==रोकथाम== | ==रोकथाम== | ||
[[File:Software bug displayed on two screens at La Croix de Berny station in France - 2021-10-28.jpg|thumb|फ़्रांस के [[ला क्रोक्स डे बर्नी स्टेशन]] पर दो स्क्रीन पर प्रदर्शित सॉफ़्टवेयर बग के परिणामस्वरूप त्रुटि।]]सॉफ़्टवेयर उद्योग ने बगों की संख्या कम करने के लिए बहुत प्रयास किए हैं।<nowiki><ref></nowiki>{{cite book | last = Huizinga | first = Dorota | author2 = Kolawa, Adam | title = स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास| url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page = 426 | isbn = 978-0-470-04212-0 | url-status = live | archive-url = https://web.archive.org/web/20120425232401/http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | archive-date = April 25, 2012 | df = mdy-all }}</ref><ref>{{cite book | last = McDonald | first = Marc | author2 = Musson, Robert | author3 = Smith, Ross | title = दोष निवारण के लिए व्यावहारिक मार्गदर्शिका| url = https://archive.org/details/practicalguideto00/page/480 | year = 2007 | publisher = Microsoft Press | page = [https://archive.org/details/practicalguideto00/page/480 480] | isbn = 978-0-7356-2253-1 | df = mdy-all | url-access = registration }}</ref> इसमे सम्मलित है: | [[File:Software bug displayed on two screens at La Croix de Berny station in France - 2021-10-28.jpg|thumb|फ़्रांस के [[ला क्रोक्स डे बर्नी स्टेशन]] पर दो स्क्रीन पर प्रदर्शित सॉफ़्टवेयर बग के परिणामस्वरूप त्रुटि।]]सॉफ़्टवेयर उद्योग ने बगों की संख्या कम करने के लिए बहुत प्रयास किए हैं।<nowiki><ref></nowiki>{{cite book | last = Huizinga | first = Dorota | author2 = Kolawa, Adam | title = स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास| url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page = 426 | isbn = 978-0-470-04212-0 | url-status = live | archive-url = https://web.archive.org/web/20120425232401/http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | archive-date = April 25, 2012 | df = mdy-all }}</ref><ref>{{cite book | last = McDonald | first = Marc | author2 = Musson, Robert | author3 = Smith, Ross | title = दोष निवारण के लिए व्यावहारिक मार्गदर्शिका| url = https://archive.org/details/practicalguideto00/page/480 | year = 2007 | publisher = Microsoft Press | page = [https://archive.org/details/practicalguideto00/page/480 480] | isbn = 978-0-7356-2253-1 | df = mdy-all | url-access = registration }}</ref> इसमे सम्मलित है:</blockquote> | ||
=== टंकण त्रुटियाँ === | === टंकण त्रुटियाँ === | ||
| Line 58: | Line 56: | ||
=== विकास के तरीके === | === विकास के तरीके === | ||
कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। [[सॉफ्टवेयर इंजीनियरिंग]] (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई | कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। [[सॉफ्टवेयर इंजीनियरिंग]] (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई विधियों को लागू करती है। उदाहरण के लिए, औपचारिक [[कार्यक्रम विनिर्देश]] कार्यक्रमों के सटीक व्यवहार को बताते हैं जिससे कि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण। | ||
[[इकाई का परीक्षण]] में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है। | [[इकाई का परीक्षण]] में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है। | ||
| Line 90: | Line 88: | ||
साधारणतयः, डिबगिंग का सबसे कठिन भाग बग ढूंढ रहा है। एक बार यह मिल जाने के बाद, इसे ठीक करना साधारणतयः अपेक्षाकृत आसान होता है। [[डिबगर|डिबगर्स]] के रूप में जाने जाने वाले प्रोग्राम प्रोग्रामर को कोड लाइन को लाइन से निष्पादित करके, चर मूल्यों को देखते हुए, और प्रोग्राम के व्यवहार को देखने के लिए अन्य सुविधाओं द्वारा बग का पता लगाने में मदद करते हैं। डिबगर के बिना, कोड जोड़ा जा सकता है जिससे कि प्रोग्राम निष्पादन का पता लगाने या मान दिखाने के लिए कंसोल या विंडो या लॉग फ़ाइल में संदेश या मान लिखे जा सकें। | साधारणतयः, डिबगिंग का सबसे कठिन भाग बग ढूंढ रहा है। एक बार यह मिल जाने के बाद, इसे ठीक करना साधारणतयः अपेक्षाकृत आसान होता है। [[डिबगर|डिबगर्स]] के रूप में जाने जाने वाले प्रोग्राम प्रोग्रामर को कोड लाइन को लाइन से निष्पादित करके, चर मूल्यों को देखते हुए, और प्रोग्राम के व्यवहार को देखने के लिए अन्य सुविधाओं द्वारा बग का पता लगाने में मदद करते हैं। डिबगर के बिना, कोड जोड़ा जा सकता है जिससे कि प्रोग्राम निष्पादन का पता लगाने या मान दिखाने के लिए कंसोल या विंडो या लॉग फ़ाइल में संदेश या मान लिखे जा सकें। | ||
चूंकि, डिबगर की सहायता से भी, बग्स का पता लगाना एक कला है। किसी प्रोग्राम के | चूंकि, डिबगर की सहायता से भी, बग्स का पता लगाना एक कला है। किसी प्रोग्राम के सेक्शन में बग के लिए यह असामान्य नहीं है कि वह पूरी तरह से अलग सेक्शन में फेल हो जाए,{{citation needed|date=November 2012}} इस प्रकार इसे ट्रैक करना विशेष रूप से कठिन बना देता है (उदाहरण के लिए, ग्राफिक्स रेंडरिंग (कंप्यूटर ग्राफिक्स) रूटीन में एक त्रुटि जिसके कारण फ़ाइल इनपुट/आउटपुट रूटीन विफल हो जाता है), सिस्टम के स्पष्ट रूप से असंबंधित भाग में। | ||
कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक भाग को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अधिकांशतः बग को पुन: पेश किए बिना त्रुटियां मिल सकती हैं। | कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक भाग को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अधिकांशतः बग को पुन: पेश किए बिना त्रुटियां मिल सकती हैं। | ||
| Line 113: | Line 111: | ||
बग प्रबंधन में सही कोड को दस्तावेज करने, वर्गीकृत करने, असाइन करने, पुनरुत्पादित करने, सही करने और जारी करने की प्रक्रिया सम्मलित है। सॉफ़्टवेयर में प्रस्तावित परिवर्तन - बग के साथ-साथ एन्हांसमेंट अनुरोध और यहां तक कि संपूर्ण रिलीज़ - को साधारणतयः [[बग ट्रैकिंग सिस्टम]] या [[ट्रैकिंग प्रणाली जारी करें]] का उपयोग करके ट्रैक और प्रबंधित किया जाता है।<ref>{{cite magazine |last=Allen |first=Mitch |date=May–June 2002 |title=बग ट्रैकिंग मूल बातें: रिपोर्टिंग और ट्रैकिंग दोषों के लिए एक शुरुआती मार्गदर्शिका|magazine=Software Testing & Quality Engineering Magazine |volume=4 |issue=3 |pages=20–24 |url=https://www.stickyminds.com/better-software-magazine/bug-tracking-basics |access-date=December 19, 2017}}</ref> जोड़ी गई वस्तुओं को दोष, टिकट, मुद्दे, या चुस्त विकास प्रतिमान, कहानियों और महाकाव्यों के बाद कहा जा सकता है। श्रेणियां वस्तुनिष्ठ, व्यक्तिपरक या एक संयोजन हो सकती हैं, जैसे कि [[संस्करण संख्या]], सॉफ़्टवेयर का क्षेत्र, गंभीरता और प्राथमिकता, साथ ही यह किस प्रकार का मुद्दा है, जैसे कि सुविधा अनुरोध या बग। | बग प्रबंधन में सही कोड को दस्तावेज करने, वर्गीकृत करने, असाइन करने, पुनरुत्पादित करने, सही करने और जारी करने की प्रक्रिया सम्मलित है। सॉफ़्टवेयर में प्रस्तावित परिवर्तन - बग के साथ-साथ एन्हांसमेंट अनुरोध और यहां तक कि संपूर्ण रिलीज़ - को साधारणतयः [[बग ट्रैकिंग सिस्टम]] या [[ट्रैकिंग प्रणाली जारी करें]] का उपयोग करके ट्रैक और प्रबंधित किया जाता है।<ref>{{cite magazine |last=Allen |first=Mitch |date=May–June 2002 |title=बग ट्रैकिंग मूल बातें: रिपोर्टिंग और ट्रैकिंग दोषों के लिए एक शुरुआती मार्गदर्शिका|magazine=Software Testing & Quality Engineering Magazine |volume=4 |issue=3 |pages=20–24 |url=https://www.stickyminds.com/better-software-magazine/bug-tracking-basics |access-date=December 19, 2017}}</ref> जोड़ी गई वस्तुओं को दोष, टिकट, मुद्दे, या चुस्त विकास प्रतिमान, कहानियों और महाकाव्यों के बाद कहा जा सकता है। श्रेणियां वस्तुनिष्ठ, व्यक्तिपरक या एक संयोजन हो सकती हैं, जैसे कि [[संस्करण संख्या]], सॉफ़्टवेयर का क्षेत्र, गंभीरता और प्राथमिकता, साथ ही यह किस प्रकार का मुद्दा है, जैसे कि सुविधा अनुरोध या बग। | ||
एक बग ट्राइएज बग की समीक्षा करता है और यह तय करता है कि उन्हें ठीक करना है या नहीं। निर्णय बग की प्राथमिकता और प्रोजेक्ट शेड्यूल जैसे कारकों पर आधारित है। ट्राइएज बग के कारण की जांच करने के लिए नहीं है, बल्कि उन्हें ठीक करने की लागत के लिए है। ट्राइएज नियमित रूप से होता है, और पिछली मीटिंग के बाद से खोले गए या फिर से खोले गए बग से गुजरता है। ट्राइएज प्रक्रिया के सहभागी साधारणतयः प्रोजेक्ट मैनेजर[[फुर्तीली विकास]] मैनेजर, टेस्ट मैनेजर, बिल्ड मैनेजर और तकनीकी विशेषज्ञ होते हैं।<ref>{{cite book| url=https://www.google.co.in/books/edition/Managing_The_Testing_Process_2Nd_Ed/XN0izRhGylYC?hl=en&gbpv=1&dq=bug+triage&pg=PA139&printsec=frontcover| title=परीक्षण प्रक्रिया का प्रबंधन (दूसरा संस्करण)| author=Rex Black| date=2002| accessdate=19 June 2021| publisher=Wiley India Pvt. Limited| isbn=9788126503131| page=139}}</ref><ref>{{cite book| url=https://www.google.co.in/books/edition/Shipping_Greatness/BKj-M_FlU_kC?hl=en&gbpv=1&dq=bug+triage&pg=PA80&printsec=frontcover| title=नौवहन महानता - उत्कृष्ट सॉफ़्टवेयर बनाने और लॉन्च करने पर व्यावहारिक पाठ, Google और Amazon पर काम के दौरान सीखे गए| author=Chris Vander Mey| date=24 August 2012| publisher=[[O'Reilly Media]]| isbn=9781449336608| pages=79–81}}</ref> | एक बग ट्राइएज बग की समीक्षा करता है और यह तय करता है कि उन्हें ठीक करना है या नहीं। निर्णय बग की प्राथमिकता और प्रोजेक्ट शेड्यूल जैसे कारकों पर आधारित है। ट्राइएज बग के कारण की जांच करने के लिए नहीं है, बल्कि उन्हें ठीक करने की लागत के लिए है। ट्राइएज नियमित रूप से होता है, और पिछली मीटिंग के बाद से खोले गए या फिर से खोले गए बग से गुजरता है। ट्राइएज प्रक्रिया के सहभागी साधारणतयः प्रोजेक्ट मैनेजर [[फुर्तीली विकास]] मैनेजर, टेस्ट मैनेजर, बिल्ड मैनेजर और तकनीकी विशेषज्ञ होते हैं।<ref>{{cite book| url=https://www.google.co.in/books/edition/Managing_The_Testing_Process_2Nd_Ed/XN0izRhGylYC?hl=en&gbpv=1&dq=bug+triage&pg=PA139&printsec=frontcover| title=परीक्षण प्रक्रिया का प्रबंधन (दूसरा संस्करण)| author=Rex Black| date=2002| accessdate=19 June 2021| publisher=Wiley India Pvt. Limited| isbn=9788126503131| page=139}}</ref><ref>{{cite book| url=https://www.google.co.in/books/edition/Shipping_Greatness/BKj-M_FlU_kC?hl=en&gbpv=1&dq=bug+triage&pg=PA80&printsec=frontcover| title=नौवहन महानता - उत्कृष्ट सॉफ़्टवेयर बनाने और लॉन्च करने पर व्यावहारिक पाठ, Google और Amazon पर काम के दौरान सीखे गए| author=Chris Vander Mey| date=24 August 2012| publisher=[[O'Reilly Media]]| isbn=9781449336608| pages=79–81}}</ref> | ||
=== गंभीरता === | === गंभीरता === | ||
गंभीरता सिस्टम संचालन पर बग के प्रभाव की तीव्रता है।<ref>{{Cite journal|last1=Soleimani Neysiani|first1=Behzad|last2=Babamir|first2=Seyed Morteza|last3=Aritsugi|first3=Masayoshi|date=2020-10-01|title=सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584920301117|journal=Information and Software Technology|language=en|volume=126|pages=106344|doi=10.1016/j.infsof.2020.106344|s2cid=219733047}}</ref> यह प्रभाव डेटा हानि, वित्तीय, सद्भावना की हानि और व्यर्थ प्रयास हो सकता है। गंभीरता का स्तर मानकीकृत नहीं है। प्रभाव उद्योग भर में भिन्न होते हैं। एक वीडियो गेम में क्रैश का प्रभाव वेब ब्राउज़र या रीयल टाइम मॉनिटरिंग सिस्टम में क्रैश की तुलना में बिल्कुल अलग होता है। उदाहरण के लिए, बग की गंभीरता का स्तर क्रैश या हैंग हो सकता है, कोई समाधान नहीं (जिसका अर्थ है कि ग्राहक किसी दिए गए कार्य को पूरा नहीं कर सकता है), समाधान है (जिसका अर्थ है कि उपयोगकर्ता अभी भी कार्य पूरा कर सकता है), दृश्य दोष (उदाहरण के लिए, | गंभीरता सिस्टम संचालन पर बग के प्रभाव की तीव्रता है।<ref>{{Cite journal|last1=Soleimani Neysiani|first1=Behzad|last2=Babamir|first2=Seyed Morteza|last3=Aritsugi|first3=Masayoshi|date=2020-10-01|title=सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584920301117|journal=Information and Software Technology|language=en|volume=126|pages=106344|doi=10.1016/j.infsof.2020.106344|s2cid=219733047}}</ref> यह प्रभाव डेटा हानि, वित्तीय, सद्भावना की हानि और व्यर्थ प्रयास हो सकता है। गंभीरता का स्तर मानकीकृत नहीं है। प्रभाव उद्योग भर में भिन्न होते हैं। एक वीडियो गेम में क्रैश का प्रभाव वेब ब्राउज़र या रीयल टाइम मॉनिटरिंग सिस्टम में क्रैश की तुलना में बिल्कुल अलग होता है। उदाहरण के लिए, बग की गंभीरता का स्तर क्रैश या हैंग हो सकता है, कोई समाधान नहीं (जिसका अर्थ है कि ग्राहक किसी दिए गए कार्य को पूरा नहीं कर सकता है), समाधान है (जिसका अर्थ है कि उपयोगकर्ता अभी भी कार्य पूरा कर सकता है), दृश्य दोष (उदाहरण के लिए, छवि या विस्थापित बटन या प्रपत्र तत्व), या दस्तावेज़ त्रुटि। कुछ सॉफ्टवेयर प्रकाशक अधिक योग्य गंभीरता का उपयोग करते हैं जैसे कि महत्वपूर्ण , उच्च , निम्न , अवरोधक या तुच्छ ।<ref>{{cite web|url=http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|title=5.3। एक बग का एनाटॉमी|work=bugzilla.org|url-status=live|archive-url=https://web.archive.org/web/20130523121753/http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|archive-date=May 23, 2013}}</ref> बग की गंभीरता को ठीक करने के लिए उसकी प्राथमिकता के लिए एक अलग श्रेणी हो सकती है, और दोनों को अलग-अलग परिमाणित और प्रबंधित किया जा सकता है। | ||
=== प्राथमिकता === | === प्राथमिकता === | ||
| Line 127: | Line 125: | ||
* एक समय सीमा पूरी होनी चाहिए और समय सीमा तक सभी बग को ठीक करने के लिए संसाधन अपर्याप्त हैं।<ref>{{cite magazine|title=द नेक्स्ट जनरेशन 1996 लेक्सिकॉन ए टू ज़ेड: स्लिपस्ट्रीम रिलीज़|magazine=[[Next Generation (magazine)|Next Generation]]|issue=15 |publisher=[[Imagine Media]]|date=March 1996|page=41}}</ref> | * एक समय सीमा पूरी होनी चाहिए और समय सीमा तक सभी बग को ठीक करने के लिए संसाधन अपर्याप्त हैं।<ref>{{cite magazine|title=द नेक्स्ट जनरेशन 1996 लेक्सिकॉन ए टू ज़ेड: स्लिपस्ट्रीम रिलीज़|magazine=[[Next Generation (magazine)|Next Generation]]|issue=15 |publisher=[[Imagine Media]]|date=March 1996|page=41}}</ref> | ||
* आगामी रिलीज़ में बग को पहले ही ठीक कर लिया गया है, और यह उच्च प्राथमिकता का नहीं है। | * आगामी रिलीज़ में बग को पहले ही ठीक कर लिया गया है, और यह उच्च प्राथमिकता का नहीं है। | ||
* बग को ठीक करने के लिए आवश्यक परिवर्तन बहुत महंगे हैं या बहुत से अन्य घटकों को प्रभावित करते हैं, जिसके लिए | * बग को ठीक करने के लिए आवश्यक परिवर्तन बहुत महंगे हैं या बहुत से अन्य घटकों को प्रभावित करते हैं, जिसके लिए प्रमुख परीक्षण गतिविधि की आवश्यकता होती है। | ||
* यह संदेहास्पद या ज्ञात हो सकता है कि कुछ उपयोगकर्ता | * यह संदेहास्पद या ज्ञात हो सकता है कि कुछ उपयोगकर्ता सम्मलित बग्गी व्यवहार पर भरोसा कर रहे हैं; एक प्रस्तावित सुधार विकट:ब्रेकिंग परिवर्तन पेश कर सकता है। | ||
* समस्या | * समस्या ऐसे क्षेत्र में है जो आगामी रिलीज़ के साथ अप्रचलित हो जाएगा; इसे ठीक करना अनावश्यक है। | ||
* यह | * यह बग नहीं है, यह एक सुविधा है ।<ref name=wired>{{cite web|url=https://www.wired.com/story/its-not-a-bug-its-a-feature/|title='यह एक बग नहीं है, यह एक सुविधा है।' ट्राइट-या जस्ट राइट?|website=wired.com|first=Nicholas |last=Carr|year=2018}}</ref> अपेक्षित और कथित व्यवहार या गैर-दस्तावेज विशेषता के बीच एक गलतफहमी पैदा हो गई है। | ||
== प्रकार == | == प्रकार == | ||
सॉफ्टवेयर विकास परियोजनाओं में, किसी भी स्तर पर गलती या त्रुटि पेश की जा सकती है। विनिर्देश, डिज़ाइन, कोडिंग, कॉन्फ़िगरेशन, डेटा प्रविष्टि या दस्तावेज़ीकरण के समय एक सॉफ़्टवेयर टीम द्वारा निरीक्षण या गलतियों से बग उत्पन्न होते हैं। उदाहरण के लिए, शब्दों की सूची को वर्णानुक्रमित करने के लिए एक अपेक्षाकृत सरल प्रोग्राम, डिज़ाइन इस बात पर विचार करने में विफल हो सकता है कि जब किसी शब्द में एक [[हैफ़ेन]] होता है तो क्या होना चाहिए। या जब | सॉफ्टवेयर विकास परियोजनाओं में, किसी भी स्तर पर गलती या त्रुटि पेश की जा सकती है। विनिर्देश, डिज़ाइन, कोडिंग, कॉन्फ़िगरेशन, डेटा प्रविष्टि या दस्तावेज़ीकरण के समय एक सॉफ़्टवेयर टीम द्वारा निरीक्षण या गलतियों से बग उत्पन्न होते हैं। उदाहरण के लिए, शब्दों की सूची को वर्णानुक्रमित करने के लिए एक अपेक्षाकृत सरल प्रोग्राम, डिज़ाइन इस बात पर विचार करने में विफल हो सकता है कि जब किसी शब्द में एक [[हैफ़ेन]] होता है तो क्या होना चाहिए। या जब अमूर्त डिजाइन को कोड में परिवर्तित करते हैं, तो कोडर अनजाने में एक-एक-एक त्रुटि बना सकता है जो एक और सूची में अंतिम शब्द को सॉर्ट करने में विफल हो सकता है। | ||
बग की एक अन्य श्रेणी को दौड़ की स्थिति कहा जाता है जो तब हो सकती है जब प्रोग्राम में एक ही समय में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के इरादे से अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना कठिन हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के समय नहीं हो सकते हैं। | बग की एक अन्य श्रेणी को दौड़ की स्थिति कहा जाता है जो तब हो सकती है जब प्रोग्राम में एक ही समय में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के इरादे से अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना कठिन हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के समय नहीं हो सकते हैं। | ||
| Line 140: | Line 138: | ||
=== अंकगणित === | === अंकगणित === | ||
संख्यात्मक मूल्यों पर संचालन में, समस्याएं उत्पन्न हो सकती हैं जिसके परिणामस्वरूप अप्रत्याशित आउटपुट, प्रक्रिया की धीमी गति या क्रैशिंग हो सकती है।<ref>{{cite web |last1=Di Franco |first1=Anthony |last2=Guo |first2=Hui |last3=Cindy |first3=Rubio-González |title=रीयल-वर्ल्ड न्यूमेरिकल बग विशेषताओं का एक व्यापक अध्ययन|url=https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-date=2022-10-09 |url-status=live}}</ref> ये डेटा स्टोरेज के गुणों के बारे में जागरूकता की कमी से हो सकते हैं जैसे [[गोलाई]], [[संख्यात्मक स्थिरता]] एल्गोरिदम, अंकगणित अतिप्रवाह और अंकगणितीय अंडरफ्लो के कारण अंकगणितीय सटीकता, या विभिन्न सॉफ्टवेयर कोडिंग भाषाओं द्वारा गणना कैसे की जाती है, इस बारे में जागरूकता की कमी से। शून्य | संख्यात्मक मूल्यों पर संचालन में, समस्याएं उत्पन्न हो सकती हैं जिसके परिणामस्वरूप अप्रत्याशित आउटपुट, प्रक्रिया की धीमी गति या क्रैशिंग हो सकती है।<ref>{{cite web |last1=Di Franco |first1=Anthony |last2=Guo |first2=Hui |last3=Cindy |first3=Rubio-González |title=रीयल-वर्ल्ड न्यूमेरिकल बग विशेषताओं का एक व्यापक अध्ययन|url=https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-date=2022-10-09 |url-status=live}}</ref> ये डेटा स्टोरेज के गुणों के बारे में जागरूकता की कमी से हो सकते हैं जैसे [[गोलाई]], [[संख्यात्मक स्थिरता]] एल्गोरिदम, अंकगणित अतिप्रवाह और अंकगणितीय अंडरफ्लो के कारण अंकगणितीय सटीकता, या विभिन्न सॉफ्टवेयर कोडिंग भाषाओं द्वारा गणना कैसे की जाती है, इस बारे में जागरूकता की कमी से। शून्य कंप्यूटर अंकगणित द्वारा विभाजन के रूप में जो कुछ भाषाओं में अपवाद फेंक सकता है, और अन्य में [[NaN]] या इन्फिनिटी कंप्यूटिंग जैसे विशेष मान लौटा सकता है। | ||
=== नियंत्रण प्रवाह === | === नियंत्रण प्रवाह === | ||
| Line 162: | Line 160: | ||
{{See also|रनटाइम त्रुटि}} | {{See also|रनटाइम त्रुटि}} | ||
* अशक्त सूचक विचलन। | * अशक्त सूचक विचलन। | ||
* | * गैर-प्रारंभिक चर का उपयोग करना। | ||
* गलत [[डेटा प्रकार]] पर अन्यथा मान्य निर्देश का उपयोग करना (पैक्ड दशमलव/[[बाइनरी-कोडित दशमलव]] देखें)। | * गलत [[डेटा प्रकार]] पर अन्यथा मान्य निर्देश का उपयोग करना (पैक्ड दशमलव/[[बाइनरी-कोडित दशमलव]] देखें)। | ||
* प्रवेश उल्लंघन। | * प्रवेश उल्लंघन। | ||
| Line 172: | Line 170: | ||
=== सिंटेक्स === | === सिंटेक्स === | ||
{{See also| | {{See also|वाक्य रचना त्रुटि}} | ||
* गलत लेक्सिकल_विश्लेषण टोकन का उपयोग, जैसे कि समानता के अतिरिक्त असाइनमेंट करना। उदाहरण के लिए, कुछ भाषाओं में <nowiki>x=5</nowiki> x का मान 5 पर सेट करेगा जबकि <nowiki>x==5</nowiki> जाँच करेगा कि x वर्तमान में 5 है या कोई अन्य संख्या। व्याख्या की गई भाषाएँ ऐसे कोड को विफल होने देती हैं। परीक्षण शुरू होने से पहले संकलित भाषाएँ ऐसी त्रुटियों को पकड़ सकती हैं। | * गलत लेक्सिकल_विश्लेषण टोकन का उपयोग, जैसे कि समानता के अतिरिक्त असाइनमेंट करना। उदाहरण के लिए, कुछ भाषाओं में <nowiki>x=5</nowiki> x का मान 5 पर सेट करेगा जबकि <nowiki>x==5</nowiki> जाँच करेगा कि x वर्तमान में 5 है या कोई अन्य संख्या। व्याख्या की गई भाषाएँ ऐसे कोड को विफल होने देती हैं। परीक्षण शुरू होने से पहले संकलित भाषाएँ ऐसी त्रुटियों को पकड़ सकती हैं। | ||
| Line 197: | Line 195: | ||
== लोकप्रिय संस्कृति में == | == लोकप्रिय संस्कृति में == | ||
* 1968 के उपन्यास 2001: ए स्पेस ओडिसी (उपन्यास) | 2001: ए स्पेस ओडिसी और संबंधित 1968 फिल्म 2001: ए स्पेस ओडिसी (फिल्म) दोनों में | 2001: ए स्पेस ओडिसी, एक अंतरिक्ष यान का ऑनबोर्ड कंप्यूटर, एचएएल 9000, करने का प्रयास करता है इसके सभी चालक दल के सदस्यों को मार डालो। अनुवर्ती 1982 के उपन्यास, 2010: ओडिसी टू, और साथ में 1984 की फिल्म, 2010 (फ़िल्म) में, यह पता चला है कि यह क्रिया कंप्यूटर द्वारा दो परस्पर विरोधी उद्देश्यों के साथ प्रोग्राम किए जाने के कारण हुई थी: इसकी सभी सूचनाओं को पूरी तरह से प्रकट करने के लिए, और चालक दल से उड़ान के असली उद्देश्य को गुप्त रखना; इस संघर्ष के कारण HAL | * 1968 के उपन्यास 2001: ए स्पेस ओडिसी (उपन्यास) | 2001: ए स्पेस ओडिसी और संबंधित 1968 फिल्म 2001: ए स्पेस ओडिसी (फिल्म) दोनों में | 2001: ए स्पेस ओडिसी, एक अंतरिक्ष यान का ऑनबोर्ड कंप्यूटर, एचएएल 9000, करने का प्रयास करता है इसके सभी चालक दल के सदस्यों को मार डालो। अनुवर्ती 1982 के उपन्यास, 2010: ओडिसी टू, और साथ में 1984 की फिल्म, 2010 (फ़िल्म) में, यह पता चला है कि यह क्रिया कंप्यूटर द्वारा दो परस्पर विरोधी उद्देश्यों के साथ प्रोग्राम किए जाने के कारण हुई थी: इसकी सभी सूचनाओं को पूरी तरह से प्रकट करने के लिए, और चालक दल से उड़ान के असली उद्देश्य को गुप्त रखना; इस संघर्ष के कारण HAL संतुलन खो बैठा और अंततः मानवघाती हो गया। | ||
* नेना 1983 के गीत [[99 गुब्बारे]] (99 लाल गुब्बारे) के अंग्रेजी संस्करण में सॉफ्टवेयर में बग के परिणामस्वरूप, 99 लाल गुब्बारों के एक समूह की रिहाई को दुश्मन के परमाणु मिसाइल लॉन्च के लिए गलत माना जाता है, जिसके लिए एक समान लॉन्च प्रतिक्रिया की आवश्यकता होती है, जिसके परिणामस्वरूप तबाही होती है। | * नेना 1983 के गीत [[99 गुब्बारे]] (99 लाल गुब्बारे) के अंग्रेजी संस्करण में सॉफ्टवेयर में बग के परिणामस्वरूप, 99 लाल गुब्बारों के एक समूह की रिहाई को दुश्मन के परमाणु मिसाइल लॉन्च के लिए गलत माना जाता है, जिसके लिए एक समान लॉन्च प्रतिक्रिया की आवश्यकता होती है, जिसके परिणामस्वरूप तबाही होती है। | ||
* 1999 की अमेरिकी कॉमेडी [[कार्यालय की जगह]] में, तीन कर्मचारियों ने एक कंप्यूटर वायरस का उपयोग करके Y2K कंप्यूटर बग के साथ अपनी कंपनी की व्यस्तता का फायदा उठाने का प्रयास (असफल) किया, जो उनके बैंक खाते में एक पैसे के राउंड-ऑफ अंश भेजता है - एक लंबे समय से ज्ञात तकनीक के रूप में वर्णित है। [[सलामी टुकड़ा करने की रणनीति]]। | * 1999 की अमेरिकी कॉमेडी [[कार्यालय की जगह]] में, तीन कर्मचारियों ने एक कंप्यूटर वायरस का उपयोग करके Y2K कंप्यूटर बग के साथ अपनी कंपनी की व्यस्तता का फायदा उठाने का प्रयास (असफल) किया, जो उनके बैंक खाते में एक पैसे के राउंड-ऑफ अंश भेजता है - एक लंबे समय से ज्ञात तकनीक के रूप में वर्णित है। [[सलामी टुकड़ा करने की रणनीति]]। | ||