सॉफ्टवेयर बग

From Vigyanwiki
श्रृंखला का हिस्सा
सूचना सुरक्षा
vectorial version
सुरक्षा संबंधित श्रेणियां
थ्रेट्स
डिफेंसेस

सॉफ़्टवेयर बग कंप्यूटर सॉफ्टवेयर के डिज़ाइन, डेवलोपमेन्ट या संचालन में एक त्रुटि, दोष या दोष (तकनीक) है जिसके कारण यह गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या अनपेक्षित विधि से व्यवहार करता है। बग को खोजने और सुधारने की प्रक्रिया को डिबगिंग कहा जाता है और अधिकांशतः बग को इंगित करने के लिए औपचारिक तकनीकों या उपकरणों का उपयोग किया जाता है। 1950 के दशक के बाद से कुछ कंप्यूटर सिस्टम संचालन के समय विभिन्न कंप्यूटर बगों को रोकने, पहचानने या स्वत। ठीक करने के लिए डिज़ाइन किए गए हैं।

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

कुछ सॉफ़्टवेयर बग्स को आपदाओं से जोड़ा गया है। 1980 के दशक में थेरेक-25 विकिरण उपचार मशीन को नियंत्रित करने वाले कोड में वॉर्म्स सीधे मरीजों की मौत के लिए जिम्मेदार थे। 1996 में, ऑन-बोर्ड मार्गदर्शन कंप्यूटर प्रोग्राम में बग के कारण यूरोपीय अंतरिक्ष एजेंसी के US$1 बिलियन प्रोटोटाइप एरियन उड़ान V88 लॉन्च के एक मिनट से भी कम समय बाद।[2] 1994 में, 1994 स्कॉटलैंड आरएएफ चिनूक दुर्घटना दुर्घटना, 29 की मौत; शुरुआत में इसे पायलट त्रुटि के लिए दोषी ठहराया गया था, लेकिन बाद में माना गया कि यह एफएडीईसी (FADEC) इंजन-कंट्रोल कंप्यूटर में एक सॉफ्टवेयर बग के कारण हुआ है।[3] बग सॉफ्टवेयर ने 21वीं सदी के आरंभिक ब्रिटिश डाकघर घोटाला का कारण बना, ब्रिटिश कानूनी इतिहास में न्याय का सबसे व्यापक गर्भपात।[4]

2002 में, अमेरिकी वाणिज्य विभाग के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा शुरू किए गए अध्ययन ने निष्कर्ष निकाला कि सॉफ्टवेयर बग, या त्रुटियां, इतनी प्रचलित और इतनी हानिकारक हैं कि वे अमेरिकी अर्थव्यवस्था को अनुमानित रूप से सकल घरेलू उत्पाद के लिए $59 बिलियन वार्षिक, या लगभग 0.6 प्रतिशत खर्च करते हैं।[5]

इतिहास

Main article: बग (इंजीनियरिंग)

मध्य अंग्रेजी शब्द 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 ओपनएसएसएल भेद्यता थी।

प्रोग्रामिंग लैंग्वेज समर्थन

प्रोग्रामिंग लैंग्वेज में बग्स को रोकने में मदद करने के लिए फीचर्स सम्मलित हैं, जैसे स्टैटिक प्रकार प्रणाली, प्रतिबंधित नाम स्थान और मॉड्यूलर प्रोग्रामिंग है। उदाहरण के लिए, जब एक प्रोग्रामर लिखता है (स्यूडोकोड) LET REAL_VALUE PI = "THREE AND A BIT", चूंकि यह वाक्यात्मक रूप से सही हो सकता है, कोड एक प्रकार की जाँच में विफल रहता है। संकलित लैंग्वेजएँ प्रोग्राम को चलाए बिना इसे पकड़ लेती हैं। व्याख्या की गई लैंग्वेजएँ रनटाइम पर ऐसी त्रुटियों को पकड़ती हैं। कुछ लैंग्वेजएं धीमी गति से प्रदर्शन की कीमत पर जानबूझकर उन विशेषताओं को बाहर करती हैं जो आसानी से बग की ओर ले जाती हैं। सामान्य सिद्धांत यह है कि, थोड़ा तेज चलने वाले रहस्यमय कोड की तुलना में सरल, धीमा कोड लिखना लगभग हमेशा बेहतर होता है, विशेष रूप से यह देखते हुए कि रखरखाव लागत पर्याप्त है . उदाहरण के लिए, जावा (प्रोग्रामिंग लैंग्वेज) पॉइंटर (कंप्यूटर प्रोग्रामिंग) अंकगणित का समर्थन नहीं करता है; पास्कल (प्रोग्रामिंग लैंग्वेज) और स्क्रिप्टिंग लैंग्वेजओं जैसी कुछ लैंग्वेजओं के कार्यान्वयन में अधिकांशतः कम से कम डिबगिंग बिल्ड में सरणी की रनटाइम सीमा जांच होती है।

कोड विश्लेषण

स्टेटिक कोड विश्लेषण के लिए उपकरण संभावित समस्याओं का पता लगाने के लिए कंपाइलर की क्षमताओं से परे प्रोग्राम टेक्स्ट का निरीक्षण करके डेवलपर्स की मदद करते हैं। चूंकि साधारणतयः एक विनिर्देश दिए गए सभी प्रोग्रामिंग त्रुटियों को खोजने की समस्या हल करने योग्य नहीं है (देखें रुकने की समस्या), ये उपकरण इस तथ्य का फायदा उठाते हैं कि मानव प्रोग्रामर अधिकांशतः सॉफ़्टवेयर लिखते समय कुछ प्रकार की सरल गलतियाँ करते हैं।

इंस्ट्रूमेंटेशन

चल रहे सॉफ़्टवेयर के प्रदर्शन की निगरानी करने के लिए उपकरण, या तो विशेष रूप से टोंटी (इंजीनियरिंग) जैसी समस्याओं का पता लगाने के लिए या कार्य को सही करने के लिए आश्वासन देने के लिए, स्पष्ट रूप से कोड में एम्बेड किया जा सकता है (इस प्रकार इस कथन के रूप में सरल PRINT "I AM HERE"), या उपकरण के रूप में प्रदान किया गया। यह अधिकांशतः आश्चर्य की बात है कि अधिकांश समय कोड के एक टुकड़े द्वारा कहाँ लिया जाता है, और मान्यताओं को हटाने से कोड को फिर से लिखा जा सकता है।

परीक्षण

सॉफ़्टवेयर परीक्षक वे लोग होते हैं जिनका प्राथमिक कार्य बग ढूंढना या परीक्षण का समर्थन करने के लिए कोड लिखना होता है। कुछ परियोजनाओं पर, कार्यक्रम विकसित करने की तुलना में परीक्षण पर अधिक संसाधन खर्च किए जा सकते हैं।

परीक्षण के समय माप शेष संभावित बगों की संख्या का अनुमान प्रदान कर सकते हैं; यह अधिक विश्वसनीय हो जाता है क्योंकि किसी उत्पाद का परीक्षण और डेवलोपमेन्ट किया जाता है।[citation needed]

डिबगिंग

सामान्य बग इतिहास (जीएनयू क्लासपाथ प्रोजेक्ट डेटा)। उपयोगकर्ता द्वारा सबमिट किया गया एक नया बग अपुष्ट है। एक बार जब इसे एक डेवलपर द्वारा पुन। प्रस्तुत किया जाता है, तो यह एक पुष्टि की गई बग है। पुष्टि किए गए बग बाद में तय किए गए हैं। अन्य श्रेणियों से संबंधित बग (पुनरुत्पादन योग्य नहीं, तय नहीं किया जाएगा, आदि) साधारणतयः अल्पमत में होते हैं
Main article: डिबगिंग

बग्स को ढूँढना और ठीक करना, या डिबगिंग, कंप्यूटर प्रोग्रामिंग का एक प्रमुख भाग है। एक शुरुआती कंप्यूटिंग अग्रणी मौरिस विल्क्स ने 1940 के दशक के अंत में अपने अहसास का वर्णन किया कि उनके जीवन का अधिकांश समय उनके अपने कार्यक्रमों में गलतियाँ खोजने में व्यतीत होगा।[24]

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

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

कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक भाग को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अधिकांशतः बग को पुन। प्रस्तुत किए बिना त्रुटियां मिल सकती हैं।

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

इनपुट से कुछ बग का पता चलता है जो प्रोग्रामर के लिए फिर से बनाना मुश्किल हो सकता है। थेराक-25 विकिरण मशीन से होने वाली मौतों का एक कारण एक बग (विशेष रूप से, एक रन की स्थिति) था जो केवल तब हुआ जब मशीन ऑपरेटर ने बहुत तेजी से एक उपचार योजना में प्रवेश किया; ऐसा करने में सक्षम होने में अभ्यास के कई दिन लग गए, इसलिए बग परीक्षण में प्रकट नहीं हुआ या जब निर्माता ने इसे डुप्लिकेट करने का प्रयास किया। बग को खोजने में मदद करने के लिए जब भी सेटअप बढ़ाया जाता है, तो अन्य बग होने बंद हो सकते हैं, जैसे प्रोग्राम को डीबगर के साथ चलाना; इन्हें हाइसनबग्स कहा जाता है (हास्यास्पद रूप से अनिश्चितता सिद्धांत के नाम पर)।

1990 के दशक के बाद से, विशेष रूप से एरियन 5 फ्लाइट 501 आपदा के बाद, डिबगिंग के लिए स्वचालित सहायता में रुचि बढ़ी, जैसे अमूर्त व्याख्या द्वारा स्थिर कोड विश्लेषण।[25]

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

बग का बेंचमार्क

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

  • सीमेंस बेंचमार्क
  • कई बग[26] नौ ओपन-सोर्स प्रोग्राम में 185 सी बग का बेंचमार्क है।
  • दोष4J[27] 5 ओपन-सोर्स प्रोजेक्ट्स से 341 Java बग्स का एक बेंचमार्क है। इसमें संबंधित पैच होते हैं, जो विभिन्न प्रकार के पैच को कवर करते हैं।[28]
  • बग्स[29] परीक्षण विफलताओं पर ध्यान केंद्रित करते हुए निरंतर एकीकरण निर्माण विफलताओं का एक बेंचमार्क है। ट्रैविस सीआई पर ओपन-सोर्स प्रोजेक्ट्स से बिल्ड की निगरानी करके इसे बनाया गया है।

बग प्रबंधन

बग प्रबंधन में सही कोड को दस्तावेज करने, वर्गीकृत करने, असाइन करने, पुनरुत्पादित करने, सही करने और जारी करने की प्रक्रिया सम्मलित है। सॉफ़्टवेयर में प्रस्तावित परिवर्तन - बग के साथ-साथ एन्हांसमेंट अनुरोध और यहां तक ​​कि संपूर्ण रिलीज़ - को साधारणतयः बग ट्रैकिंग सिस्टम या ट्रैकिंग प्रणाली जारी करें का उपयोग करके ट्रैक और प्रबंधित किया जाता है।[30] जोड़ी गई वस्तुओं को दोष, टिकट, विवाद, या अगिल डेवलोपमेन्ट प्रतिमान, कहानियों और महाकाव्यों के बाद कहा जा सकता है। श्रेणियां वस्तुनिष्ठ, व्यक्तिपरक या एक संयोजन हो सकती हैं, जैसे कि संस्करण संख्या, सॉफ़्टवेयर का क्षेत्र, गंभीरता और प्राथमिकता, साथ ही यह किस प्रकार का मुद्दा है, जैसे कि सुविधा अनुरोध या बग।

एक बग ट्राइएज बग की समीक्षा करता है और यह तय करता है कि उन्हें ठीक करना है या नहीं। निर्णय बग की प्राथमिकता और प्रोजेक्ट शेड्यूल जैसे कारकों पर आधारित है। ट्राइएज बग के कारण की जांच करने के लिए नहीं है, बल्कि उन्हें ठीक करने की लागत के लिए है। ट्राइएज नियमित रूप से होता है, और पिछली मीटिंग के बाद से खोले गए या फिर से खोले गए बग से गुजरता है। ट्राइएज प्रक्रिया के सहभागी साधारणतयः प्रोजेक्ट, टेस्ट मैनेजर, बिल्ड मैनेजर और तकनीकी विशेषज्ञ होते हैं।[31][32]

गंभीरता

गंभीरता सिस्टम संचालन पर बग के प्रभाव की तीव्रता है।[33] यह प्रभाव डेटा हानि, वित्तीय, सद्भावना की हानि और व्यर्थ प्रयास हो सकता है। गंभीरता का स्तर मानकीकृत नहीं है। प्रभाव उद्योग भर में भिन्न होते हैं। एक वीडियो गेम में क्रैश का प्रभाव वेब ब्राउज़र या रीयल टाइम मॉनिटरिंग सिस्टम में क्रैश की तुलना में बिल्कुल अलग होता है। उदाहरण के लिए, बग की गंभीरता का स्तर क्रैश या हैंग हो सकता है, कोई समाधान नहीं (जिसका अर्थ है कि ग्राहक किसी दिए गए कार्य को पूरा नहीं कर सकता है), समाधान है (जिसका अर्थ है कि उपयोगकर्ता अभी भी कार्य पूरा कर सकता है), दृश्य दोष (उदाहरण के लिए, छवि या विस्थापित बटन या प्रपत्र तत्व), या दस्तावेज़ त्रुटि। कुछ सॉफ्टवेयर प्रकाशक अधिक योग्य गंभीरता का उपयोग करते हैं जैसे कि महत्वपूर्ण, उच्च , निम्न, अवरोधक या तुच्छ।[34] बग की गंभीरता को ठीक करने के लिए उसकी प्राथमिकता के लिए एक अलग श्रेणी हो सकती है, और दोनों को अलग-अलग परिमाणित और प्रबंधित किया जा सकता है।

प्राथमिकता

नियोजित परिवर्तनों की सूची में बग आने पर प्राथमिकता नियंत्रण। प्रत्येक सॉफ्टवेयर निर्माता द्वारा प्राथमिकता तय की जाती है। प्राथमिकताएं संख्यात्मक हो सकती हैं, जैसे 1 से 5, या नामित, जैसे महत्वपूर्ण, उच्च, निम्न, या स्थगित। ये रेटिंग स्केल गंभीरता रेटिंग के समान या समान हो सकते हैं, लेकिन बग की गंभीरता को ठीक करने के अनुमानित प्रयास के संयोजन के रूप में मूल्यांकन किया जाता है; कम गंभीरता वाला लेकिन आसानी से ठीक होने वाला बग मध्यम गंभीरता वाले बग की तुलना में उच्च प्राथमिकता प्राप्त कर सकता है जिसे ठीक करने के लिए अत्यधिक प्रयास की आवश्यकता होती है। प्राथमिकता रेटिंग को उत्पाद रिलीज़ के साथ संरेखित किया जा सकता है, जैसे कि महत्वपूर्ण प्राथमिकता उन सभी बगों को इंगित करती है जिन्हें अगले सॉफ़्टवेयर रिलीज़ से पहले ठीक किया जाना चाहिए।

उत्पाद की रिलीज में देरी या रोक लगाने के लिए पर्याप्त गंभीर बग को शो स्टॉपर कहा जाता है[35] या शोस्टॉपर बग। [36] इसका नाम इसलिए रखा गया है क्योंकि यह शो को रोकता है - अस्वीकार्य उत्पाद विफलता का कारण बनता है।[36]


सॉफ्टवेयर रिलीज

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

किसी सॉफ़्टवेयर प्रकाशक द्वारा किसी विशेष बग को पैच न करने या यहां तक ​​कि उसे ठीक न करने का विकल्प चुनने के कारणों में सम्मलित हैं।

  • एक समय सीमा पूरी होनी चाहिए और समय सीमा तक सभी बग को ठीक करने के लिए संसाधन अपर्याप्त हैं।[37]
  • आगामी रिलीज़ में बग को पहले ही ठीक कर लिया गया है, और यह उच्च प्राथमिकता का नहीं है।
  • बग को ठीक करने के लिए आवश्यक परिवर्तन बहुत महंगे हैं या बहुत से अन्य घटकों को प्रभावित करते हैं, जिसके लिए प्रमुख परीक्षण गतिविधि की आवश्यकता होती है।
  • यह संदेहास्पद या ज्ञात हो सकता है कि कुछ उपयोगकर्ता सम्मलित बग्गी व्यवहार पर भरोसा कर रहे हैं; इस प्रस्तावित सुधार विकट ब्रेकिंग परिवर्तन प्रस्तुत कर सकता है।
  • समस्या ऐसे क्षेत्र में है जो आगामी रिलीज़ के साथ अप्रचलित हो जाएगा; इसे ठीक करना अनावश्यक है।
  • यह बग नहीं है, यह एक सुविधा है।[38] अपेक्षित और कथित व्यवहार या गैर-दस्तावेज विशेषता के बीच गलतफहमी पैदा हो गई है।

प्रकार

सॉफ्टवेयर डेवलोपमेन्ट परियोजनाओं में, किसी भी स्तर पर गलती या त्रुटि प्रस्तुत की जा सकती है। विनिर्देश, डिज़ाइन, कोडिंग, कॉन्फ़िगरेशन, डेटा प्रविष्टि या दस्तावेज़ीकरण के समय एक सॉफ़्टवेयर टीम द्वारा निरीक्षण या गलतियों से बग उत्पन्न होते हैं। उदाहरण के लिए, शब्दों की सूची को वर्णानुक्रमित करने के लिए एक अपेक्षाकृत सरल प्रोग्राम, डिज़ाइन इस बात पर विचार करने में विफल हो सकता है कि जब किसी शब्द में हैफ़ेन होता है तो क्या होना चाहिए। या जब अमूर्त डिजाइन को कोड में परिवर्तित करते हैं, तो कोडर अनजाने में एक-एक त्रुटि बना सकता है जो सूची में अंतिम शब्द को सॉर्ट करने में विफल हो सकता है।

बग की अन्य श्रेणी को रन की स्थिति कहा जाता है जो उसी समय हो सकता है जब प्रोग्राम में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना कठिन हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के समय नहीं हो सकते हैं।

वैचारिक त्रुटियां एक डेवलपर की गलती है कि सॉफ्टवेयर को क्या करना चाहिए। परिणामी सॉफ़्टवेयर डेवलपर की समझ के अनुसार प्रदर्शन कर सकता है, लेकिन वह नहीं जो वास्तव में आवश्यक है। इसके अन्य प्रकार इस प्रकार हैं।

अंकगणित

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

नियंत्रण प्रवाह

See also: तर्क त्रुटि

नियंत्रण प्रवाह बग वे हैं जो वैध तर्क के साथ प्रक्रियाओं में पाए जाते हैं, लेकिन इससे अनपेक्षित परिणाम होते हैं, जैसे अनंत लूप और अनंत रिकर्सन (कंप्यूटर विज्ञान), सशर्त बयानों के लिए गलत तुलना जैसे गलत असमानता का उपयोग करना, और ऑफ-बाय-वन त्रुटियां (लूप करते समय एक बहुत अधिक या एक बहुत कम पुनरावृत्तियों को गिनना)।

इंटरफेसिंग

  • गलत एपीआई उपयोग।[40]
  • गलत प्रोटोकॉल कार्यान्वयन।
  • गलत हार्डवेयर हैंडलिंग।
  • किसी विशेष मंच की गलत धारणाएँ।
  • असंगत सिस्टम। एक नया एपीआई या संचार प्रोटोकॉल काम करता प्रतीत हो सकता है जब दो सिस्टम अलग-अलग संस्करणों का उपयोग करते हैं, लेकिन त्रुटियां तब हो सकती हैं जब एक संस्करण में कार्यान्वित फ़ंक्शन या सुविधा दूसरे में बदल जाती है या गायब हो जाती है। उत्पादन प्रणालियों में जिन्हें लगातार चलना चाहिए, एक प्रमुख अद्यतन के लिए पूरे सिस्टम को बंद करना संभव नहीं हो सकता है, जैसे कि दूरसंचार उद्योग में[41] या इंटरनेट।[42][43][44] इस स्थिति में, एक बड़े नेटवर्क के व्यवधान को कम करने के लिए, एक बड़े सिस्टम के छोटे सेगमेंट को व्यक्तिगत रूप से अपग्रेड किया जाता है। चूंकि, कुछ अनुभागों को अनदेखा किया जा सकता है और अपग्रेड नहीं किया जा सकता है, और संगतता त्रुटियों का कारण बन सकता है जिन्हें ढूंढना और सुधारना मुश्किल हो सकता है।
  • गलत कोड एनोटेशन[45]

मल्टी-थ्रेडिंग

  • गतिरोध, जहाँ कार्य A तब तक जारी नहीं रह सकता जब तक कि कार्य B समाप्त नहीं हो जाता, लेकिन उसी समय, कार्य B तब तक जारी नहीं रह सकता जब तक कि कार्य A समाप्त नहीं हो जाता।
  • रन की स्थिति, जहां कंप्यूटर प्रोग्रामर के इच्छित क्रम में कार्य नहीं करता है।
  • महत्वपूर्ण वर्गों में समवर्ती त्रुटियां, आपसी बहिष्करण और समवर्ती प्रोग्रामिंग की अन्य विशेषताएं संसाधनों तक पहुंच का समन्वय। टाइम-ऑफ-चेक-टू-टाइम-ऑफ-यूज (TOCTOU) असुरक्षित महत्वपूर्ण अनुभाग का एक रूप है।

संसाधन

See also: रनटाइम त्रुटि
  • अशक्त सूचक विचलन।
  • गैर-प्रारंभिक चर का उपयोग करना।
  • गलत डेटा प्रकार पर अन्यथा मान्य निर्देश का उपयोग करना (पैक्ड दशमलव/बाइनरी-कोडित दशमलव देखें)।
  • प्रवेश उल्लंघन।
  • रिसोर्स लीक, जहां एक परिमित सिस्टम रिसोर्स (जैसे स्मृति रिसाव या रिसाव को संभालें) बिना रिलीज के बार-बार आवंटन से समाप्त हो जाता है।
  • बफ़र अधिकता, जिसमें एक प्रोग्राम आवंटित स्टोरेज के अंत से पहले डेटा स्टोर करने की कोशिश करता है। इससे एक्सेस उल्लंघन या स्टोरेज उल्लंघन हो सकता है या नहीं भी हो सकता है। इन्हें सुरक्षा बग के रूप में जाना जाता है।
  • अत्यधिक पुनरावर्तन जो - चूंकि तार्किक रूप से मान्य है - ढेर अतिप्रवाह का कारण बनता है।
  • यूज-आफ्टर-फ्री एरर, जहां एक पॉइंटर (कंप्यूटर प्रोग्रामिंग) का उपयोग सिस्टम द्वारा उस मेमोरी को मुक्त करने के बाद किया जाता है जिसका वह संदर्भ देता है।
  • डबल फ्री एरर।

सिंटेक्स

See also: वाक्य रचना त्रुटि
  • गलत लेक्सिकल_विश्लेषण टोकन का उपयोग, जैसे कि समानता के अतिरिक्त असाइनमेंट करना। उदाहरण के लिए, कुछ लैंग्वेजओं में x=5 x का मान 5 पर सेट करेगा जबकि x==5 जाँच करेगा कि x वर्तमान में 5 है या कोई अन्य संख्या। व्याख्या की गई लैंग्वेजएँ ऐसे कोड को विफल होने देती हैं। परीक्षण शुरू होने से पहले संकलित लैंग्वेजएँ ऐसी त्रुटियों को पकड़ सकती हैं।

टीम वर्क

  • अप्रचारित अद्यतन; उदा. प्रोग्रामर myAdd को बदल देता है लेकिन mySubtract को बदलना भूल जाता है, जो उसी एल्गोरिथम का उपयोग करता है। इन त्रुटियों को डोंट रिपीट योरसेल्फ या डोंट रिपीट योरसेल्फ फिलॉसफी द्वारा कम किया जाता है।
  • टिप्पणियाँ पुरानी या गलत हैं। कई प्रोग्रामर मानते हैं कि टिप्पणियाँ कोड का सटीक वर्णन करती हैं।
  • प्रलेखन और उत्पाद के बीच अंतर।

निहितार्थ

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

वॉर्म्स से होने वाली क्षति के अतिरिक्त, उनकी कुछ लागत उन्हें ठीक करने में किए गए प्रयास के कारण होती है। 1978 में, लिएंट्ज़ एट अल। दिखाया गया है कि बग फिक्सिंग में परियोजनाओं का माध्य डेवलोपमेन्ट के प्रयास का 17 प्रतिशत निवेश करता है।[46] 2020 में गिट हब (GitHub) रिपॉजिटरी पर शोध में दिखाया गया है कि माध्य 20% है।[47]

वितरित उत्पाद में अवशिष्ट बग

1994 में, नासा के गोडार्ड अंतरिक्ष उड़ान केंद्र ने त्रुटियों की औसत संख्या 4.5 प्रति 1000 लाइन कोड (कोड की सोर्स लाइन) से घटाकर 1 प्रति 1000 SLOC करने में अपना योगदान दिया।[48]

1990 में एक अन्य अध्ययन ने बताया कि असाधारण रूप से अच्छी सॉफ्टवेयर डेवलोपमेन्ट प्रक्रियाएँ 0.1 प्रति 1000 SLOC के रूप में परिनियोजन विफलता दर प्राप्त कर सकती हैं।[49] यह आंकड़ा साहित्य में पुनरावृत्त है जैसे स्टीव मैककोनेल द्वारा कोड पूर्ण,[50] और नासा अध्ययन उड़ान सॉफ्टवेयर जटिलता पर।[51] कुछ परियोजनाओं में शून्य दोष भी पाए गए। आईबीएम व्हीलराइटर टाइपराइटर में फर्मवेयर जिसमें 63,000 एसएलओसी सम्मलित हैं, और 500,000 एसएलओसी के साथ अंतरिक्ष शटल सॉफ्टवेयर।[49]

प्रसिद्ध बग

Main article: सॉफ़्टवेयर बग की सूची

कई सॉफ़्टवेयर बग प्रसिद्ध हो गए हैं, साधारणतयः उनकी गंभीरता के कारण। उदाहरणों में विभिन्न अंतरिक्ष और सैन्य विमान दुर्घटनाएं सम्मलित हैं। संभवतः सबसे प्रसिद्ध बग वर्ष 2000 की समस्या या Y2K बग है, जिसके कारण 19xx से 20xx तारीखों में परिवर्तन से बहुत पहले लिखे गए कई कार्यक्रम खराब हो गए थे, उदाहरण के लिए 25 दिसंबर 04 जैसी तारीख को 1904 में मानते हुए, 19100 के अतिरिक्त 19100 प्रदर्शित करना 2000, और इतने पर। 20वीं शताब्दी के अंत में एक बड़े प्रयास ने सबसे गंभीर समस्याओं का समाधान किया, और कोई बड़ा परिणाम नहीं हुआ।

नाइट कैपिटल ग्रुप 2012 स्टॉक ट्रेडिंग व्यवधान में पुराने एपीआई और नए एपीआई के बीच एक ऐसी असंगति सम्मलित थी।

लोकप्रिय संस्कृति में

  • 1968 के उपन्यास 2001। ए स्पेस ओडिसी (उपन्यास) | 2001। ए स्पेस ओडिसी और संबंधित 1968 फिल्म 2001। ए स्पेस ओडिसी (फिल्म) दोनों में | 2001। ए स्पेस ओडिसी, एक अंतरिक्ष यान का ऑनबोर्ड कंप्यूटर, एचएएल 9000, करने का प्रयास करता है इसके सभी चालक दल के सदस्यों को मार डालो। अनुवर्ती 1982 के उपन्यास, 2010। ओडिसी टू, और साथ में 1984 की फिल्म, 2010 (फ़िल्म) में, यह पता चला है कि यह क्रिया कंप्यूटर द्वारा दो परस्पर विरोधी उद्देश्यों के साथ प्रोग्राम किए जाने के कारण हुई थी। इसकी सभी सूचनाओं को पूरी तरह से प्रकट करने के लिए, और चालक दल से उड़ान के असली उद्देश्य को गुप्त रखना; इस संघर्ष के कारण HAL संतुलन खो बैठा और अंततः मानवघाती हो गया।
  • नेना 1983 के गीत 99 गुब्बारे (99 लाल गुब्बारे) के अंग्रेजी संस्करण में सॉफ्टवेयर में बग के परिणामस्वरूप, 99 लाल गुब्बारों के एक समूह की रिहाई को दुश्मन के परमाणु मिसाइल लॉन्च के लिए गलत माना जाता है, जिसके लिए एक समान लॉन्च प्रतिक्रिया की आवश्यकता होती है, जिसके परिणामस्वरूप तबाही होती है।
  • 1999 की अमेरिकी कॉमेडी कार्यालय की जगह में, तीन कर्मचारियों ने एक कंप्यूटर वायरस का उपयोग करके Y2K कंप्यूटर बग के साथ अपनी कंपनी की व्यस्तता का फायदा उठाने का प्रयास (असफल) किया, जो उनके बैंक खाते में एक पैसे के राउंड-ऑफ अंश भेजता है - एक लंबे समय से ज्ञात तकनीक के रूप में वर्णित है। सलामी टुकड़ा करने की रणनीति।
  • 2004 का उपन्यास द बग, एलेन उल्मैन द्वारा, डेटाबेस एप्लिकेशन में एक मायावी बग खोजने के प्रोग्रामर के प्रयास के बारे में है।[52]
  • 2008 की कनाडाई फिल्म नियंत्रण ऑल्ट डिलीट (फ़िल्म)फिल्म) 1999 के अंत में एक कंप्यूटर प्रोग्रामर के बारे में है जो अपनी कंपनी में वर्ष 2000 की समस्या से संबंधित बग को ठीक करने के लिए संघर्ष कर रहा है।

यह भी देखें

संदर्भ

  1. ↑ Mittal, Varun; Aditya, Shivam (2015-01-01). "बग फिक्सिंग के क्षेत्र में हालिया विकास". Procedia Computer Science. International Conference on Computer, Communication and Convergence (ICCC 2015) (in English). 48: 288–297. doi:10.1016/j.procs.2015.04.184. ISSN 1877-0509.
  2. ↑ "एरियन 501 - पूछताछ बोर्ड की रिपोर्ट की प्रस्तुति". www.esa.int (in English). Retrieved 2022-01-29.
  3. ↑ Prof. Simon Rogerson. "चिनूक हेलीकाप्टर आपदा". Ccsr.cse.dmu.ac.uk. Archived from the original on July 17, 2012. Retrieved September 24, 2012.
  4. ↑ "पोस्ट ऑफिस स्कैंडल ने बर्बाद की जिंदगी, जांच में सुनवाई". BBC News. 14 February 2022.
  5. ↑ "सॉफ्टवेयर बग अमेरिकी अर्थव्यवस्था को महंगा पड़ा". June 10, 2009. Archived from the original on June 10, 2009. Retrieved September 24, 2012.{{cite web}}: CS1 maint: unfit URL (link)
  6. ↑ Computerworld staff (September 3, 2011). "मशीन में कीट: 'बग' की उत्पत्ति को डीबग करना". Computerworld. Archived from the original on August 25, 2015.
  7. ↑ "bug". Oxford English Dictionary (Online ed.). Oxford University Press. (Subscription or participating institution membership required.) 5a
  8. ↑ "क्या तुम्हें पता था? एडिसन ने "बग" शब्द गढ़ा". August 1, 2013. Retrieved July 19, 2019.
  9. ↑ "बाफल बॉल". Internet Pinball Database. (संदर्भ प्रविष्टि में विज्ञापन की छवि देखें)
  10. ↑ "आधुनिक विमान वाहक 20 वर्षों के स्मार्ट प्रयोग का परिणाम हैं". Life. June 29, 1942. p. 25. Archived from the original on June 4, 2013. Retrieved November 17, 2011.
  11. ↑ Dickinson Rich, Louise (1942), We Took to the Woods, JB Lippincott Co, p. 93, LCCN 42024308, OCLC 405243, archived from the original on March 16, 2017.
  12. ↑ James S. Huggins. "पहला कंप्यूटर बग". Jamesshuggins.com. Archived from the original on August 16, 2000. Retrieved September 24, 2012.
  13. ↑ "Bug Archived March 23, 2017, at the Wayback Machine", The Jargon File, ver. 4.4.7. Retrieved June 3, 2010.
  14. ↑ 14.0 14.1 "Log Book With Computer Bug Archived March 23, 2017, at the Wayback Machine", National Museum of American History, Smithsonian Institution.
  15. ↑ "The First "Computer Bug", Naval Historical Center. But note the Harvard Mark II computer was not complete until the summer of 1947.
  16. ↑ IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000
  17. ↑ Journal of the Royal Aeronautical Society. 49, 183/2, 1945 "It ranged ... through the stage of type test and flight test and 'debugging' ..."
  18. ↑ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. "सिस्टम में कीड़े" (PDF). Open Policy Institute. Archived (PDF) from the original on September 21, 2016. Retrieved August 22, 2016.
  19. ↑ 19.0 19.1 19.2 "एसईआई 1999 आर्काइव पर समाचार". cmu.edu. Archived from the original on May 26, 2013.
  20. ↑ Shustek, Len (August 2, 2016). "इन हिज ओन वर्ड्स: गैरी किल्डाल". Remarkable People. Computer History Museum. Archived from the original on December 17, 2016.
  21. ↑ McDonald, Marc; Musson, Robert; Smith, Ross (2007). दोष निवारण के लिए व्यावहारिक मार्गदर्शिका. Microsoft Press. p. 480. ISBN 978-0-7356-2253-1.
  22. ↑ "Release Early, Release Often" Archived May 14, 2011, at the Wayback Machine, Eric S. Raymond, The Cathedral and the Bazaar
  23. ↑ "Wide Open Source" Archived September 29, 2007, at the Wayback Machine, Elias Levy, SecurityFocus, April 17, 2000
  24. ↑ Maurice Wilkes Quotes
  25. ↑ "पॉलीस्पेस टेक्नोलॉजीज इतिहास". christele.faure.pagesperso-orange.fr. Retrieved August 1, 2019.
  26. ↑ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "सी प्रोग्राम्स की स्वचालित मरम्मत के लिए मैनीबग्स और इंट्रोक्लास बेंचमार्क". IEEE Transactions on Software Engineering. 41 (12): 1236–1256. doi:10.1109/TSE.2015.2454513. ISSN 0098-5589.
  27. ↑ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: a database of existing faults to enable controlled testing studies for Java programs". सॉफ्टवेयर परीक्षण और विश्लेषण पर 2014 अंतर्राष्ट्रीय संगोष्ठी की कार्यवाही - आईएसएसटीए 2014. pp. 437–440. CiteSeerX 10.1.1.646.3086. doi:10.1145/2610384.2628055. ISBN 9781450326452. S2CID 12796895.
  28. ↑ Sobreira, Victor; Durieux, Thomas; Madeiral, Fernanda; Monperrus, Martin; de Almeida Maia, Marcelo (2018). "Dissection of a bug dataset: Anatomy of 395 patches from Defects4J". 2018 IEEE सॉफ्टवेयर विश्लेषण, विकास और पुनर्रचना पर 25वां अंतर्राष्ट्रीय सम्मेलन (SANER). pp. 130–140. arXiv:1801.06393. doi:10.1109/SANER.2018.8330203. ISBN 978-1-5386-4969-5. S2CID 4607810.
  29. ↑ Madeiral, Fernanda; Urli, Simon; Maia, Marcelo; Monperrus, Martin; Maia, Marcelo A. (2019). "BEARS: An Extensible Java Bug Benchmark for Automatic Program Repair Studies". 2019 IEEE सॉफ्टवेयर विश्लेषण, विकास और पुनर्रचना (SANER) पर 26वां अंतर्राष्ट्रीय सम्मेलन. pp. 468–478. arXiv:1901.06024. doi:10.1109/SANER.2019.8667991. ISBN 978-1-7281-0591-8. S2CID 58028949.
  30. ↑ Allen, Mitch (May–June 2002). "बग ट्रैकिंग मूल बातें: रिपोर्टिंग और ट्रैकिंग दोषों के लिए एक शुरुआती मार्गदर्शिका". Software Testing & Quality Engineering Magazine. Vol. 4, no. 3. pp. 20–24. Retrieved December 19, 2017.
  31. ↑ Rex Black (2002). परीक्षण प्रक्रिया का प्रबंधन (दूसरा संस्करण). Wiley India Pvt. Limited. p. 139. ISBN 9788126503131. Retrieved 19 June 2021.
  32. ↑ Chris Vander Mey (24 August 2012). नौवहन महानता - उत्कृष्ट सॉफ़्टवेयर बनाने और लॉन्च करने पर व्यावहारिक पाठ, Google और Amazon पर काम के दौरान सीखे गए. O'Reilly Media. pp. 79–81. ISBN 9781449336608.
  33. ↑ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020-10-01). "सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल". Information and Software Technology (in English). 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  34. ↑ "5.3। एक बग का एनाटॉमी". bugzilla.org. Archived from the original on May 23, 2013.
  35. ↑ Jones, Wilbur D. Jr., ed. (1989). "शो स्टोपर". Glossary : defense acquisition acronyms and terms (in English) (4 ed.). Fort Belvoir, Virginia, USA: Department of Defense, Defense Systems Management College. p. 123. hdl:2027/mdp.39015061290758. hdl:2027/mdp.39015061290758 – via Hathitrust.
  36. ↑ 36.0 36.1 Zachary, G. Pascal (1994). शो स्टोपर! : Microsoft में Windows NT और अगली पीढ़ी बनाने के लिए ख़तरनाक दौड़ (in English). New York, NY, USA: The Free Press. p. 158. ISBN 0029356717 – via archive.org.
  37. ↑ "द नेक्स्ट जनरेशन 1996 लेक्सिकॉन ए टू ज़ेड: स्लिपस्ट्रीम रिलीज़". Next Generation. No. 15. Imagine Media. March 1996. p. 41.
  38. ↑ Carr, Nicholas (2018). "'यह एक बग नहीं है, यह एक सुविधा है।' ट्राइट-या जस्ट राइट?". wired.com.
  39. ↑ Di Franco, Anthony; Guo, Hui; Cindy, Rubio-González. "रीयल-वर्ल्ड न्यूमेरिकल बग विशेषताओं का एक व्यापक अध्ययन" (PDF). Archived (PDF) from the original on 2022-10-09.
  40. ↑ Monperrus, Martin; Bruch, Marcel; Mezini, Mira (2010). "Detecting Missing Method Calls in Object-Oriented Software". ECOOP 2010 - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (PDF). Lecture Notes in Computer Science. Vol. 6183. pp. 2–25. doi:10.1007/978-3-642-14107-2_2. ISBN 978-3-642-14106-5. S2CID 16724498. Archived (PDF) from the original on 2022-10-09.
  41. ↑ Kimbler, K. (1998). दूरसंचार और सॉफ्टवेयर सिस्टम्स में फ़ीचर इंटरेक्शन V. IOS Press. p. 8. ISBN 978-90-5199-431-5.
  42. ↑ Syed, Mahbubur Rahman (July 1, 2001). मल्टीमीडिया नेटवर्किंग: प्रौद्योगिकी, प्रबंधन और अनुप्रयोग: प्रौद्योगिकी, प्रबंधन और अनुप्रयोग. Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9.
  43. ↑ Wu, Chwan-Hwa (John); Irwin, J. David (April 19, 2016). कंप्यूटर नेटवर्क और साइबर सुरक्षा का परिचय. CRC Press. p. 500. ISBN 978-1-4665-7214-0.
  44. ↑ RFC 1263: "TCP Extensions Considered Harmful" quote: "the time to distribute the new version of the protocol to all hosts can be quite long (forever in fact). ... If there is the slightest incompatibly between old and new versions, chaos can result."
  45. ↑ Yu, Zhongxing; Bai, Chenggang; Seinturier, Lionel; Monperrus, Martin (2019). "अभ्यास में जावा एनोटेशन के उपयोग, विकास और प्रभाव की विशेषता". IEEE Transactions on Software Engineering. 47 (5): 1. arXiv:1805.01965. doi:10.1109/TSE.2019.2910516. S2CID 102351817.
  46. ↑ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (1978). "एप्लिकेशन सॉफ़्टवेयर रखरखाव के लक्षण". Communications of the ACM. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091.
  47. ↑ Amit, Idan; Feitelson, Dror G. (2020). "सुधारात्मक प्रतिबद्धता संभाव्यता कोड गुणवत्ता मीट्रिक". arXiv:2007.10912 [cs.SE].
  48. ↑ सॉफ्टवेयर इंजीनियरिंग प्रयोगशाला का अवलोकन (pdf) (Report) (in English). Maryland, USA: Goddard Space Flight Center, NASA. 1994-12-01. pp41–42 Figure 18; pp43–44 Figure 21. CR-189410; SEL-94-005. Archived (PDF) from the original on 2022-11-22. Retrieved 2022-11-22. (bibliography: An overview of the Software Engineering Laboratory)
  49. ↑ 49.0 49.1 Cobb, Richard H.; Mills, Harlan D. (1990). "सांख्यिकीय गुणवत्ता नियंत्रण के तहत इंजीनियरिंग सॉफ्टवेयर". IEEE Software (in English). 7 (6): 46. doi:10.1109/52.60601. ISSN 1937-4194 – via University of Tenessee – Harlan D. Mills Collection.
  50. ↑ McConnell, Steven C. (1993). कोड पूर्ण (in English). Redmond, Washington, USA: Microsoft Press. p. 611. ISBN 9781556154843 – via archive.org. (कॉब एंड मिल्स 1990)
  51. ↑ Holzmann, Gerard (2009-03-06). "Appendix D – Software Complexity". In Dvorak, Daniel L. (ed.). उड़ान सॉफ्टवेयर जटिलता पर नासा का अध्ययन (pdf) (Report) (in English). NASA. pdf frame 109/264. Appendix D p.2. Archived (PDF) from the original on 2022-03-08. Retrieved 2022-11-22. (under NASA Office of the Chief Engineer Technical Excellence Initiative)
  52. ↑ Ullman, Ellen (2004). बग. Picador. ISBN 978-1-250-00249-5.

बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_बग&oldid=257793’