क्या बग को ठीक करने में मामूली लाभ है [बंद]

Question

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

इस अवधारणा के बारे में हमारे उत्पाद के मालिक को समझाने के प्रयास में, मुझे कोई अच्छा संसाधन नहीं मिला। मुझे केवल इतना पता चला कि सॉफ्टवेयर विकास में मामूली लागत है या नहीं।

क्या कीड़े को ठीक करने में वास्तव में मामूली लाभ है? क्या कोई अलग शब्द है जो इस अवधारणा की व्याख्या करता है?

Comments

देखें कि मैं $ {कुछ} को $ {किसी} को कैसे समझाऊं?

— gnat

आपका प्रश्न काफी अस्पष्ट है। "सभी कीड़े को ठीक करने की आवश्यकता नहीं है" का अर्थ है कि कुछ ऐसे हैं जो तय होने के लायक नहीं हैं। "क्या कीड़े को ठीक करने में वास्तव में मामूली लाभ है" मुझे लगता है कि आपका मतलब कुछ अलग है। क्या आप समझा सकते हैं?

— डॉक ब्राउन

क्या यह उत्पाद स्वामी का पता लगाने के लिए नहीं है? आपको क्यों लगता है कि आपको इसके बारे में उन्हें समझाने की ज़रूरत है?

— मोनिका

@ गोया मैं यह सवाल विशेष रूप से उन्हें समझाने के लिए नहीं कह रहा हूं। यह एक अवधारणा थी जिसका मैंने कुछ समय पहले सामना किया था लेकिन कोई और संसाधन नहीं मिला। इसके अलावा सॉफ्टवेयर डेवलपर के लिए प्रबंधन की स्थिति में होना असामान्य नहीं है। इसलिए मुझे भविष्य में इस जानकारी की आवश्यकता हो सकती है।

— गोचन कर्ट

@ GökhanKurt: यह "सभी कीड़े को ठीक करने के लिए आवश्यक हैं" से पालन नहीं करता है कि वे सभी समान रूप से महत्वपूर्ण हैं। कुछ दूसरों की तुलना में अधिक विघटनकारी हो सकते हैं और उनकी उच्च प्राथमिकता होती है।

— जैक्सबी

Answer 1

व्यावसायिक दृष्टिकोण से, बग फिक्स सुविधा अनुरोध से अलग नहीं है। विकास के समय में इसकी एक निश्चित लागत होती है, और ग्राहकों के लिए इसका एक निश्चित मूल्य होता है। यदि एक बग गैर-महत्वपूर्ण है, तो यह बगफिक्स के ऊपर एक मूल्यवान सुविधा को प्राथमिकता देने के लिए पूरी तरह से अच्छा व्यापार समझ बना सकता है।

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

प्राथमिकता देते समय इन सभी कारकों को ध्यान में रखा जाना चाहिए।

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

Comments

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

— डोभाल

@ डोवल तुम गलत समझ रहे हो। जैक्स ने कहा कि एक ऐसी विशेषता थी जो अभी तक नहीं लिखी गई है, इसकी लागत नहीं है। या दूसरे शब्दों में, एक सुविधा न होना एक अलग विशेषता को लागू करने के लिए कठिन नहीं बनाता है (जब तक कि उत्तरार्द्ध पूर्व पर निर्भर नहीं होता है, निश्चित रूप से)। एक बग, दूसरी ओर, इसे ठीक करने के अलावा और कुछ भी करना मुश्किल बनाता है। जैसे, "अलिखित सुविधाएँ" और "अनफ्रीगेटेड बग्स" अलग हैं, इसमें पूर्व आपके कोड आधार को प्रभावित नहीं करता है, जबकि बाद वाला करता है।

— सेबेस्टियन रेडल सेप

मैं यह जोड़ना चाहता हूं कि कार्यक्रम की छवि पर एक बग का भी बड़ा प्रभाव हो सकता है (और इसलिए उत्पाद का एक संपूर्ण के रूप में, और कंपनी ने इसे उत्पादित किया है) ... इसे ध्यान में रखा जाना चाहिए: क्या कोई ऐसा करना चाहता है एक बग छोड़ दें, यदि मिल जाए, तो कंपनी को कुछ ग्राहकों और / या व्यवसाय का खर्च उठाना पड़ सकता है?

— ओलिवियर दुलक

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

— निधि मोनिका का मुकदमा

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

— जॉन बेंटले

Answer 2

यहाँ एक अच्छा संदर्भ है

http://www.joelonsoftware.com/articles/fog0000000043.html

क्या आप नया कोड लिखने से पहले बग को ठीक करते हैं? विंडोज के लिए माइक्रोसॉफ्ट वर्ड के पहले संस्करण को "डेथ मार्च" प्रोजेक्ट माना गया था। [...] क्योंकि बग फिक्सिंग चरण औपचारिक कार्यक्रम का हिस्सा नहीं था [...]

Microsoft ने सार्वभौमिक रूप से कुछ अपनाया [...] सर्वोच्च प्राथमिकता किसी भी नए कोड को लिखने से पहले बग को खत्म करना है [...] सामान्य तौर पर, आप बग को ठीक करने से पहले जितना लंबा इंतजार करते हैं, उतना ही महंगा (समय और धन) इसे ठीक करना है ।

आप यह सुनिश्चित कर सकते हैं कि अब वे बग जितने लंबे समय तक यहां रहेंगे, प्राथमिकता बनने के बाद उन्हें ठीक करने में उतना ही समय लगेगा। इसलिए अभी कच्चा लाभ होने के बजाय, आप भविष्य में एक महंगा नुकसान से बच रहे हैं।

प्रबंधन का एक अच्छा तरीका बैकलॉग मुद्दों से निपटने के लिए आवंटित समय की मात्रा को परिभाषित करना होगा। जैसा कि Microsoft ने किया था, यह भविष्य में आने वाली समस्याओं को हल नहीं करेगा, क्योंकि यदि ग्राहक वास्तव में परवाह नहीं करते हैं तो भी यह आपकी समस्याओं को हल करेगा।

Answer 3

इस अवधारणा के बारे में हमारे उत्पाद के मालिक को समझाने के प्रयास में, मुझे कोई अच्छा संसाधन नहीं मिला।

मान लें कि आप एक वाणिज्यिक संगठन के लिए काम कर रहे हैं, तो निश्चित रूप से वहाँ कोई होगा जो लागत-लाभ विश्लेषण के बारे में जानता हो ।

आपके संगठन के पास डेवलपर संसाधन की एक सीमित मात्रा और लाभदायक चीजों की एक अनंत सूची है। उन लाभकारी चीजों में नई सुविधाएँ जोड़ना और मौजूदा बग्स को हटाना दोनों शामिल हैं - बग को हटाने से सॉफ्टवेयर में सुधार होता है, जैसे कि एक नई सुविधा को जोड़ना।

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

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

सॉफ्टवेयर इंजीनियरिंग पर इन दो पदों को यहां भी देखें:

किस कीड़े को हल करने से सबसे बड़ी लागत लाभ मिलेगा

लगभग हर रिपोर्ट किया गया बग एक उच्च प्राथमिकता वाला बग है

Answer 4

सॉफ़्टवेयर व्यवहार के सभी अनजाने या अवांछनीय पहलू बग नहीं हैं। यह महत्वपूर्ण है कि यह सुनिश्चित करने के लिए कि सॉफ्टवेयर में उपयोगी और प्रलेखित श्रेणी है, जिसमें इसे उपयोगी फैशन में संचालित करने के लिए भरोसा किया जा सकता है। उदाहरण के लिए, एक कार्यक्रम, जिसे दो संख्याओं को स्वीकार करना चाहिए, उन्हें गुणा करें, और परिणामों को आउटपुट करें, और जो परिणाम के 9.95 से अधिक, लेकिन 10.00 से कम, 99.95 से अधिक, लेकिन 100.00 से कम हो, आदि पर एक बोगस संख्या को आउटपुट करता है। । यदि प्रोग्राम को उन संख्याओं के प्रसंस्करण के उद्देश्य से लिखा गया था, जिनका उत्पाद 3 और 7 के बीच था, और किसी भी अन्य को संसाधित करने के लिए कभी नहीं बुलाया जाएगा, 9.95 के साथ अपने व्यवहार को ठीक करने से यह अपने इच्छित उद्देश्य के लिए और अधिक उपयोगी नहीं होगा। हालाँकि, यह कार्यक्रम को अन्य उद्देश्यों के लिए अधिक उपयुक्त बना सकता है।

उपरोक्त जैसी स्थिति में, कार्रवाई के दो उचित पाठ्यक्रम होंगे:

1. समस्या को ठीक करें, यदि ऐसा करना व्यावहारिक है।

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

दृष्टिकोण # 1 बग को समाप्त कर देगा। दृष्टिकोण # 2 प्रगति को कुछ उद्देश्यों के लिए कम उपयुक्त बना सकता है, अन्यथा हो सकता है, लेकिन अगर समस्याग्रस्त मूल्यों को संभालने के लिए कार्यक्रमों की कोई आवश्यकता नहीं है, तो समस्या नहीं हो सकती है।

भले ही 99.95 से 100.0 मानों को सही ढंग से संभालने में असमर्थता एक प्रोग्रामिंग गलती का परिणाम है [उदाहरण के लिए दशमलव बिंदु के बाईं ओर दो अंकों को आउटपुट करने का निर्णय लेने के बाद एक स्थान पर चक्कर लगाने से पहले, इस प्रकार 00.00 उपज], इसे केवल माना जाना चाहिए। बग यदि प्रोग्राम अन्यथा ऐसे मामलों में सार्थक आउटपुट के रूप में निर्दिष्ट किया जाएगा। [संयोग से, उपरोक्त समस्या टर्बो सी 2.00 प्रिंटफ कोड में हुई; उस संदर्भ में, यह स्पष्ट रूप से एक बग है, लेकिन कोड जो दोषपूर्ण प्रिंटफ कहता है, केवल छोटी गाड़ी होगी यदि यह समस्याग्रस्त सीमाओं में आउटपुट का उत्पादन कर सकता है]।

Answer 5

ढीले अर्थों में, हां, सभी बगों को ठीक करने की आवश्यकता नहीं है। यह सभी जोखिम / लाभ अनुपात का विश्लेषण करने के बारे में है।

आम तौर पर क्या होता है व्यवसाय में बग्स पर चर्चा करने के लिए तकनीकी लीड्स और स्टेकहोल्डर्स के साथ एक बैठक होगी जो स्पष्ट रूप से 'ढेर' को ठीक करने की आवश्यकता नहीं है। वे तय करेंगे कि बग को ठीक करने में लगाया गया समय (= पैसा) व्यापार के लिए इसके लायक होगा या नहीं।

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

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

व्यवसाय के अन्य कारणों में बग को ठीक नहीं करना हो सकता है कि निवेश किया गया समय परियोजना को अप्रत्याशित समय में वापस लौटा देगा, या यह कि डेवलपर का समय अन्य फिक्स / कोडिंग पर काम करने में बेहतर होगा। यह भी हो सकता है कि बग इतना छोटा हो कि वह लाइव हो सके, और फिर बाद की तारीख में तय किया जा सके।

आशा है कि अवधारणा को थोड़ा बेहतर समझा जाए! मैं निश्चित रूप से सामान्य रूप से इस बारे में सोचने से दूर रहूंगा - हर बग अद्वितीय है और इसे इस तरह से माना जाना चाहिए।

Answer 6

क्योंकि जब आप बग्स की प्राथमिकता सूची में जाते हैं, तो उपयोग मामला जो कि बग अधिक अस्पष्ट हो जाता है, या ग्राहक की संतुष्टि कम हो जाती है।

तो उनका "तर्क" वास्तव में है

यदि आप बग को लंबे समय तक अनदेखा करते हैं, तो उपयोगकर्ता यह भूल जाएगा कि समस्या क्या थी या इसके चारों ओर काम करने का कोई तरीका खोजा।

बग्स को प्राथमिकता दी जानी चाहिए और नए फीचर रिक्वेस्ट की तरह "ऑर्डर" से निपटना चाहिए (लेकिन, यकीनन, बाद के सभी पर और ऊपर)।

Comments

नहींं, उनका तर्क है कि कम-प्राथमिकता वाले कीड़े केवल शायद ही कभी हो सकते हैं, और वास्तव में सही करने में बहुत अधिक मूल्य नहीं जोड़ सकते हैं (उदाहरण के लिए, यदि आपके पास अपनी वेबसाइट पर एक घड़ी है जो आधा मिनट बाहर है, या यदि आप वेबसाइट हैं जनवरी की आधी रात को मोल्दोवा में उपयोगकर्ताओं के लिए पहली त्रुटि)

— प्रदर्शन नाम