बग घनत्व के लिए कोड मेट्रिक्स सहसंबंधी प्रयोग


16

मुझे आश्चर्य है कि अगर किसी ने ऑब्जेक्ट ओरिएंटेड एप्लिकेशन में बग घनत्व के साथ कोड मेट्रिक्स (SLOC, साइक्लोमैटिक कॉम्प्लेक्सिटी, आदि) के सहसंबंधी प्रयोग किए हैं।

मैं ऐसे प्रयोगों की तलाश नहीं कर रहा हूं जो केवल एक सहसंबंध को साबित या बाधित करें, लेकिन दोनों पर। मैं एक चांदी की गोली खोजने के लिए के रूप में मुझे विश्वास है कि एक परियोजना के बग घनत्व की कोशिश कर नहीं कर रहा हूँ हो सकता है एक दिया परियोजना या टीम के लिए एक या अधिक मीट्रिक से संबद्ध हों और सहसंबंध परियोजना / टीम के जीवनकाल के दौरान बदल सकते हैं।

मेरा लक्ष्य है

  1. 2-3 महीने के लिए सभी दिलचस्प मैट्रिक्स को मापें (हम पहले से ही सोनार से काफी कम हैं)।
  2. एक ऐसे मीट्रिक को ढूंढें जो नए बग की संख्या के साथ संबंध रखता है।
  3. ऐसा क्यों होता है यह जांचने के लिए एक मूल कारण विश्लेषण करें (जैसे क्या हमारे पास एक निश्चित डिज़ाइन कौशल की कमी है?)।
  4. कौशल में सुधार और पुनरावृत्तियों के एक जोड़े के लिए परिवर्तन को मापने।
  5. 2 से कुल्ला और दोहराएं।

यदि आपके पास इस पर कोई अनुभव नहीं है, लेकिन इस विषय पर एक पेपर / ब्लॉग देखकर याद रखें, अगर आप इसे साझा कर सकते हैं, तो मैं सराहना करूंगा।


अब तक मुझे इस विषय के बारे में कुछ जानकारी के साथ निम्नलिखित लिंक मिल गए हैं


1
यदि आप बंद होने से बचना चाहते हैं, तो आपको अपने प्रश्न को दोहराना चाहिए। स्टैक एक्सचेंज साइटें खोज इंजन नहीं हैं और उपयोगकर्ता व्यक्तिगत अनुसंधान सहायक नहीं हैं । कागजात के लिंक के लिए पूछने के बजाय, यह पूछने पर जोर दिया जाना चाहिए कि किस प्रकार के मैट्रिक्स को दोषों और दोष घनत्व के साथ सहसंबद्ध किया गया है।
थॉमस ओवेन्स

1
मुझे खेद है कि प्रश्न मेरे व्यक्तिगत खोज सहायक बनने के अनुरोध के रूप में सामने आया , यह निश्चित रूप से वह नहीं है जो मैं करना चाहता था, लेकिन इस प्रकार के कागजात ढूंढना बहुत सामान्य बात नहीं है। मैंने शीर्षक बदल दिया है ताकि अन्य लोगों को समान धारणा न हो।
अगस्तो

जवाबों:


11

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

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

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

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

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

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

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


Halstead मेट्रिक्स सभी को कच्चे SLOC (कोड की स्रोत लाइनों की संख्या) के साथ दृढ़ता से सहसंबद्ध दिखाया गया है। उस समय, किसी भी Halstead मीट्रिक के साथ सहसंबद्ध होने वाली किसी भी चीज़ को कच्चे SLOC के साथ संबद्ध माना जाता है, और किसी भी Halstead मेट्रिक्स की तुलना में SLOC को मापना आसान होता है।
जॉन आर। स्ट्रॉहेम

@ JohnR.Strohm मैं इस बात से सहमत नहीं हूं कि Halstead मेट्रिक्स की तुलना में SLOC को गिनना आसान है, जब आप कम्प्यूटेशन करने के लिए टूल का उपयोग कर रहे हैं। यह मानते हुए कि हाल्टेड मेट्रिक्स वैध हैं (जिस पर वास्तव में बहस की जाती है, लेकिन अमान्य मीट्रिक के लिए कुछ भी मायने नहीं रखता है), कोड को विकसित करने के लिए आवश्यक समय की मात्रा जानना या सिस्टम में दोषों की अनुमानित संख्या राशि जानने के बाद अधिक उपयोगी मूल्य है। लाइनों की। मैं समय डेटा के साथ शेड्यूल का निर्माण कर सकता हूं, दोष डेटा के साथ गुणवत्ता योजनाएं, या कठिनाई के साथ कोड समीक्षा के लिए पर्याप्त समय आवंटित कर सकता हूं। उन चीजों के लिए कच्चे SLOC का उपयोग करना कठिन है।
थॉमस ओवेन्स

@ JohnR.Strohm मुझे यकीन है कि एक Halstead मीट्रिक संगणना कार्यक्रम SLI गिनती कार्यक्रम की तुलना में निष्पादित करने में थोड़ा अधिक समय लेता है। लेकिन मान्य आउटपुट एक निर्णय लेने में मान्य इनपुट बन जाता है, मेरे पास कच्चे एसएलओसी गणना की तुलना में सार्थक समय, प्रयास और दोष डेटा होगा। अधिक जटिल मीट्रिक का अतिरिक्त मूल्य अक्सर अतिरिक्त गणना समय के लायक होता है, फिर से मान्य इनपुट और गणना के मान्य आउटपुट मान लेता है।
थॉमस ओवेन्स

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

@ThomasOwens: इसके अलावा, किसी को यह पहचानना होगा कि हाल्टेड मेट्रिक्स स्वाभाविक रूप से पूर्वव्यापी हैं। आप अभी तक नहीं लिखे गए सॉफ़्टवेयर के Halstead मेट्रिक्स को माप सकते हैं। दूसरी ओर, किसी दिए गए कार्य के लिए कच्चे एसएलओसी का अनुमान लगाना संभव है, और, विस्तृत पर्याप्त विनिर्देशों और थोड़े अनुभव को देखते हुए, अनुमान पर बहुत करीब आना आसान है। इसके अलावा, वास्तविक रूप से अनुमानों की तुलना करना, अनुमान लगाने वाले अनुमानों की बारीकियों की तुलना करना और किसी के लागत अनुमानक को कैलिब्रेट करना बहुत आसान है। जनरल डायनेमिक्स / फोर्ट वर्थ ने 1980 के दशक की शुरुआत में इस पर बहुत काम किया।
बजे जॉन आर। स्ट्रॉह्म जूल

7

मैंने अपने ब्लॉग पोस्ट में संभावित सहसंबंधों पर चर्चा की है :

Cyclomatic जटिलता और कीड़े घनत्व के बीच भ्रष्टाचार: क्या यह वास्तविक मुद्दा है?

जवाब न है। आकार को स्थिर रखते हुए, अध्ययन सीसी और दोष घनत्व के बीच कोई संबंध नहीं दिखाता है। हालांकि, अध्ययन करने के लिए अन्य दो दिलचस्प सहसंबंध हैं:

पहले एक है: क्या सीसी दोषों का पता लगाने और ठीक करने की अवधि के साथ दृढ़ता से संबंध रखता है? दूसरे शब्दों में, यदि CC कम है, तो क्या हम कम समय डिबग और दोषों को ठीक करेंगे?

दूसरा एक है: क्या CC फॉल्ट फीडबैक रेशो (FFR, दोषों की औसत संख्या जो एक परिवर्तन को लागू करने या एक दोष को ठीक करने से उत्पन्न होता है) के साथ दृढ़ता से संबंध रखता है?

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

यह एक अच्छा प्रयोग है। परिणामों के लिए सतर्क रहें!


एक पतन के योग्य नहीं है, लेकिन यह होना चाहिए "कुछ अध्ययनों का कोई संबंध नहीं है", क्योंकि अन्य अध्ययन एक सहसंबंध दिखाते हैं।
डेविड हैमेन

3

किताब कोड कम्प्लीट, पी .457 में, स्टीव मैककोनेल का कहना है कि "नियंत्रण-प्रवाह जटिलता महत्वपूर्ण है क्योंकि इसे कम विश्वसनीयता और लगातार त्रुटियों के साथ सहसंबद्ध किया गया है"। उसके बाद वे कुछ संदर्भों का उल्लेख करते हैं जो उस सहसंबंध का समर्थन करते हैं, जिसमें खुद मैकाबे भी शामिल हैं (जिन्हें चक्रीय जटिलता मीट्रिक विकसित करने का श्रेय दिया जाता है)। इनमें से अधिकांश पूर्व-उन्मुख भाषाओं का व्यापक उपयोग करते हैं, लेकिन जैसा कि यह मीट्रिक उन भाषाओं के तरीकों पर लागू होता है, संदर्भ वे हो सकते हैं जो आप खोज रहे हैं।

वे संदर्भ हैं:

  • मैककेबे, टॉम। 1976. "एक जटिलता उपाय।" आईईईई सॉफ्टवेयर इंजीनियरिंग, एसई -2 पर लेनदेन, नहीं। 4 (दिसंबर): 308-20
  • शेन, विंसेंट वाई।, एट अल। 1985. "एरर-प्रोन सॉफ्टवेयर की पहचान - एक अनुभवजन्य अध्ययन।" सॉफ्टवेयर इंजीनियरिंग एसई -11 पर IEEE लेनदेन, नंबर 4 (अप्रैल): 317-24।
  • वार्ड, विलियम टी। 1989. "मैककेबे की जटिलता मेट्रिक का उपयोग करके सॉफ्टवेयर दोष निवारण।" हेवलेट-पैकर्ड जर्नल, अप्रैल, 64-68।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.