सीएमएमआई के लिए एमएसएफ में एक बग और एक परिवर्तन अनुरोध के बीच क्या अंतर है?

मैं वर्तमान में अपनी विकास टीम के उपयोग के लिए TFS के तहत एमएसएफ के लिए सीएमएमआई प्रक्रिया टेम्पलेट का मूल्यांकन कर रहा हूं, और मुझे अलग-अलग बग की आवश्यकता को समझने में परेशानी हो रही है और अनुरोध कार्य बदल रहा है आइटम प्रकार

मैं समझता हूं कि रिपोर्ट उत्पन्न करते समय बग (त्रुटियों) और अनुरोधों को बदलने (आवश्यकताओं को बदलने) के बीच अंतर करने में सक्षम होना फायदेमंद है।

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

बग के लिए अलग वर्कफ़्लो रखने के क्या फायदे हैं?

मैं इस तथ्य से भी उलझन में हूं कि डेवलपर्स एक बग के खिलाफ या एक बग के खिलाफ काम सबमिट कर सकते हैं, मैंने सोचा था कि इच्छित वर्कफ़्लो परिवर्तनों को उत्पन्न करने के लिए बग के लिए था, जो परिवर्तन करते समय डेवलपर संदर्भों के बारे में बताते हैं।

0
ro fr bn

5 उत्तर

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

0
जोड़ा

एक बग ऐसा कुछ है जो एक आवश्यकता में टूटा हुआ है जिसे कार्यान्वयन के लिए पहले से ही मंजूरी दे दी गई है।

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

दोनों सीएमएम के तहत मौलिक रूप से अलग हैं।

0
जोड़ा

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

एक बग आपके प्रोग्राम कार्यान्वयन में एक दोष है। उदाहरण के लिए, यदि आप अपने प्रोग्राम को दो नंबर जोड़ने और उपयोगकर्ता को योग देने में सक्षम होने के लिए डिज़ाइन करते हैं, तो एक दोष यह होगा कि यह नकारात्मक संख्याओं को सही तरीके से संभाल नहीं लेता है, और इस प्रकार एक बग।

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

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


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

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

0
जोड़ा

@Luke

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

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

हालांकि, अगर होम पेज का रंग लाल होने के लिए डिज़ाइन किया गया था, और लाल है, लेकिन किसी को लगता है कि इसे नीले रंग की जरूरत है, यानी, मेरे लिए, एक अलग प्रकार का परिवर्तन। उदाहरण के लिए, क्या किसी ने पृष्ठ के अन्य हिस्सों पर होने वाले प्रभाव के बारे में सोचा है, जैसे नीली पृष्ठभूमि को ओवरले करने वाली छवियों और लोगो? क्या ऐसी चीजों की सीमाएं हो सकती हैं जो खराब दिखती हैं? लिंक रेखांकन नीला है, क्या वह दिखाएगा?

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

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

हालांकि, एक बग यह है कि किसी ने कहा इस तरह हम इसे करने जा रहे हैं और फिर किसी ने इसे अलग किया।

एक परिवर्तन अनुरोध जैसा है और हमें इस अन्य चीज़ पर भी विचार करने की आवश्यकता है ... हम्म ...

पाठ्यक्रम के अपवाद हैं, लेकिन मुझे अपने उदाहरण अलग करने दें।

यदि 300,000,000,000 से अधिक पृष्ठदृश्यों को संभालने के लिए सर्वर डिज़ाइन किया गया था, तो हाँ, यह एक बग है जो यह नहीं करता है। लेकिन कई पेजव्यू को संभालने के लिए सर्वर को डिज़ाइन करना सिर्फ यह कहने से अधिक है कि हमारे सर्वर को 300,000,000,000 पृष्ठदृश्यों को संभालना चाहिए , इसमें बहुत विस्तृत विनिर्देश होना चाहिए कि यह कैसे कर सकता है, दाएं समय गारंटी और डिस्क पहुंच औसत समय प्रसंस्करण करने के लिए नीचे। यदि कोड को तब डिज़ाइन किया गया है, जैसा कि डिज़ाइन किया गया है, और अपेक्षित प्रदर्शन करने में असमर्थ है, तो सवाल बन जाता है: क्या हमने इसे गलत तरीके से डिजाइन किया है या क्या हमने इसे गलत तरीके से कार्यान्वित किया है?

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

हालांकि, अगर कोई इस बात पर ध्यान देने में असफल रहा है कि कैसे RAID डिस्क संचालित होती है और धारीदार मीडिया से सही तरीके से लाभ कैसे प्राप्त किया जाता है, तो यह एक बग है और इसे ठीक करने के लिए बड़े बदलाव की आवश्यकता नहीं हो सकती है।

फिर, निश्चित रूप से अपवाद होंगे।

किसी भी मामले में, मैंने जो मूल अंतर बताया है वह वह है जिसे मैंने ज्यादातर मामलों में सच पाया है।

0
जोड़ा

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

तो - आम तौर पर बोलते हुए - एक "चेंज अनुरोध" शुरू किया जाएगा और किसी संगठन द्वारा अपेक्षाकृत उच्च (किसी प्रायोजन "अधिकार वाले किसी व्यक्ति द्वारा संसाधनों को खर्च करने से संबंधित (संभवतः बहुत बड़ा) सिस्टम में परिवर्तन करने के लिए अधिकार किया जाएगा। आखिरकार यह व्यक्ति यह स्वीकार करने वाला व्यक्ति होगा कि परिवर्तन सफलतापूर्वक किया गया था।

हालांकि "बग" के लिए, एप्लिकेशन का कोई भी उपयोगकर्ता बग शुरू करने में सक्षम होना चाहिए।

एक संगठन में मैंने टीएफएस लागू किया, केवल विभाग प्रमुख "परिवर्तन अनुरोध" के उत्प्रेरक हो सकते हैं - लेकिन "सहायता डेस्क" टिकटों से "बग" बनाए गए थे (स्वचालित नहीं, केवल प्रक्रिया के माध्यम से ...)

0
जोड़ा