दोष घनत्व क्या है? उदाहरण के साथ गणना करने का सूत्र
थॉमस हैमिल्टन
⚡ स्मार्ट सारांश
डिफेक्ट डेंसिटी किसी सॉफ्टवेयर मॉड्यूल में पुष्ट दोषों की संख्या को उस मॉड्यूल के आकार से विभाजित करके मापती है, जिसे आमतौर पर कोड की प्रति हजार पंक्तियों के हिसाब से व्यक्त किया जाता है, और यह संकेत देती है कि कोई बिल्ड रिलीज़ के लिए तैयार है या नहीं।
दोष घनत्व क्या है?
दोष घनत्व किसी सॉफ़्टवेयर या मॉड्यूल में एक निश्चित परिचालन या विकास अवधि के दौरान पुष्टि की गई कमियों की संख्या को उस सॉफ़्टवेयर या मॉड्यूल के आकार से विभाजित करके निकाला जाता है। इससे टीम को यह तय करने में मदद मिलती है कि कोई सॉफ़्टवेयर रिलीज़ के लिए तैयार है या नहीं।
डिफेक्ट डेंसिटी की गणना प्रति हजार लाइन कोड के हिसाब से की जाती है, जिसे KLOC भी कहा जाता है। चूंकि गणना को आकार के अनुसार सामान्यीकृत किया जाता है, इसलिए कई दोषों वाले एक बड़े मॉड्यूल और कम दोषों वाले एक छोटे मॉड्यूल की तुलना एक ही पैमाने पर की जा सकती है, जो कि केवल बग की संख्या गिनने से संभव नहीं है।
यह मीट्रिक सामान्यतः परीक्षण चक्र के अंत में रिपोर्ट किया जाता है और tracयह रिलीज़ दर रिलीज़ जारी होता है, इसलिए यह बाकी के साथ ही रहता है। दोष प्रबंधन प्रक्रिया में सॉफ्टवेयर परीक्षण जीवन चक्र.
दोष घनत्व की गणना कैसे करें
दोष घनत्व मापने का सूत्र:
Defect Density = Defect count/size of the release
रिलीज के आकार को कोड की एक पंक्ति (LOC) के रूप में मापा जा सकता है।
तीन बातें तय करती हैं कि परिणामी संख्या का कोई अर्थ है या नहीं:
- आकार इकाई। LOC और KLOC सबसे आम इकाइयाँ हैं। फंक्शन पॉइंट्स का उपयोग वहाँ किया जाता है जहाँ टीमें एक ऐसे आकार माप की तलाश में होती हैं जो प्रोग्रामिंग भाषा के साथ न बदले, और कुछ टीमें इसके बजाय मॉड्यूल या कंपोनेंट के आधार पर मानकीकरण करती हैं।
- किसे दोष माना जाता है? अंश में केवल पुष्ट दोषों को ही शामिल किया जाना चाहिए। डुप्लिकेट, अस्वीकृत रिपोर्ट और सुधार अनुरोधों को शामिल नहीं किया जाना चाहिए, अन्यथा कोड की गुणवत्ता में कोई बदलाव किए बिना ही आंकड़ा बढ़ जाएगा।
- मापन विंडो। सिस्टम परीक्षण के दौरान पाई गई खामियाँ, प्रतिगमन परीक्षणऔर रिलीज के बाद अलग-अलग चीजों का वर्णन किया जाता है, इसलिए अवधि को संख्या के साथ बताना होगा।
दोष घनत्व उदाहरण
मान लीजिए कि आपके सॉफ़्टवेयर उत्पाद में 3 मॉड्यूल एकीकृत हैं। प्रत्येक मॉड्यूल में निम्नलिखित संख्या में बग पाए गए हैं:
- मॉड्यूल 1 = 10 बग
- मॉड्यूल 2 = 20 बग
- मॉड्यूल 3 = 10 बग
कुल बग = 10+20+10 = 40
प्रत्येक मॉड्यूल के लिए कोड की कुल पंक्तियाँ इस प्रकार हैं:
- मॉड्यूल 1 = 1000 LOC
- मॉड्यूल 2 = 1500 LOC
- मॉड्यूल 3 = 500 LOC
कुल पंक्ति Code = 1000+1500+500 = 3000
दोष घनत्व की गणना इस प्रकार की जाती है:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
प्रत्येक मॉड्यूल के लिए समान गणना लागू करना संयुक्त आंकड़े की तुलना में अधिक उपयोगी है, जैसा कि नीचे दिए गए चार्ट में दिखाया गया है: मॉड्यूल 2 में 1500 LOC में 20 दोष हैं और मॉड्यूल 3 में केवल 500 LOC में 10 दोष हैं, इसलिए मॉड्यूल 3 दोनों में से अधिक सघन और जोखिम भरा है, भले ही इसमें कम बग रिपोर्ट किए गए हों।
दोष घनत्व के लिए एक मानक
दोष घनत्व के लिए कोई निश्चित मानक नहीं है। अध्ययनों से पता चलता है कि एक दोष प्रति हजार लाइन कोड की संख्या को आम तौर पर अच्छी परियोजना गुणवत्ता का संकेत माना जाता है, और यह आंकड़ा उद्योग में सबसे व्यापक रूप से उद्धृत किया जाने वाला सामान्य नियम है।
अपेक्षा क्षेत्र के अनुसार बदलती रहती है। सुरक्षा की दृष्टि से महत्वपूर्ण और विनियमित सॉफ़्टवेयर, जैसे कि विमानन उपकरण और चिकित्सा उपकरण, के लिए प्रति किलोलॉक संख्या एक दोष से काफी कम का लक्ष्य रखा जाता है, जबकि सामान्य व्यावसायिक अनुप्रयोगों में यह लक्ष्य अक्सर इससे अधिक होता है। क्योंकि गणना के नियम, आकार इकाइयाँ और परीक्षण की गहराई सभी संगठनों में भिन्न होती हैं, इसलिए किसी प्रकाशित अध्ययन से लिया गया बेंचमार्क केवल उसी परियोजना से तुलनीय होता है जिसमें मापन विधि समान हो। अतः इस मीट्रिक का व्यावहारिक उपयोग आंतरिक होता है: एक रिलीज़ की तुलना उसी उत्पाद की पिछली रिलीज़ से करें, जिसका मापन समान तरीके से किया गया हो।
दोष घनत्व को प्रभावित करने वाले कारक
एक ही कोड बेस से उत्पन्न होने वाले दोष घनत्व के आंकड़े निम्नलिखित कारकों पर निर्भर करते हुए बहुत भिन्न हो सकते हैं:
- Code जटिलता। गहन रूप से अंतर्निर्मित तर्क और उच्च चक्रीय जटिलता यह सीधे-सादे कोड की तुलना में प्रति पंक्ति अधिक दोष उत्पन्न करता है।
- जिन प्रकार की कमियों को ध्यान में रखा गया है। केवल कार्यात्मक दोषों की गणना करना, या उपयोगिता, दस्तावेज़ीकरण और अन्य चीज़ों को शामिल करना गैर कार्यात्मक निष्कर्ष, अंश को काफी हद तक बदल देता है।
- विचाराधीन समय अवधि। दो सप्ताह के परीक्षण चक्र में मापा गया आंकड़ा छह महीने के उत्पादन उपयोग में मापे गए आंकड़े के तुलनीय नहीं है।
- डेवलपर और टेस्टर कौशल। अनुभवी डेवलपर कम दोष उत्पन्न करते हैं, और अनुभवी परीक्षक मौजूद दोषों में से अधिक को ढूंढ निकालते हैं, इसलिए दोनों प्रभाव मीट्रिक को विपरीत दिशाओं में खींचते हैं।
- परीक्षण कवरेज. जिन दोषों की कभी जांच नहीं की गई, उन्हें कभी गिना नहीं जाता, इसलिए परीक्षण कवरेज यह चुपचाप मापी गई घनत्व की अधिकतम सीमा निर्धारित करता है।
दोष घनत्व बनाम अन्य दोष मापक
डिफेक्ट डेंसिटी एक सवाल का जवाब देती है: ज्ञात डिफेक्ट कितने केंद्रित हैं। इसके साथ उपयोग होने वाले तीन अन्य मेट्रिक्स उन सवालों के जवाब देते हैं जिनका जवाब यह नहीं दे पाती, और अधिकांश टीमें इन्हें एक साथ रिपोर्ट करती हैं।
| मैट्रिक | यह क्या मापता है | प्रश्न इसका उत्तर है |
| दोष घनत्व | आकार के आधार पर पुष्ट दोषों का विभाजन (KLOC या फ़ंक्शन पॉइंट्स) | अपने आकार के हिसाब से किन मॉड्यूल में सबसे अधिक दोष पाए जाते हैं? |
| दोष रिसाव | रिलीज के बाद पाई गई कमियां, सभी कमियों के एक हिस्से के रूप में | परीक्षण प्रक्रिया से कितना हिस्सा बच निकला और उपयोगकर्ताओं तक पहुंचा? |
| दोष निवारण दक्षता | सभी दोषों के एक हिस्से के रूप में रिलीज़ से पहले दूर किए गए दोष। | समय रहते दोषों को पकड़ने में परीक्षण कितना प्रभावी रहा? |
| दोष गंभीरता सूचकांक | दोषों को समान रूप से गिनने के बजाय उनकी गंभीरता के आधार पर भारित किया जाता है। | इन दोषों की संख्या कितनी है, यह नहीं बल्कि इनसे कितना नुकसान होता है? |
इन चारों को एक साथ पढ़ने से एक अधिक संपूर्ण तस्वीर सामने आती है: उच्च दोष रिसाव के साथ कम दोष घनत्व, स्वच्छ कोड के बजाय सतही परीक्षण की ओर इशारा करता है, जो कि ठीक वही गलतफहमी है जिसके बारे में अगले अनुभाग में चेतावनी दी गई है।
दोष घनत्व के लाभ
दोष घनत्व के निम्नलिखित लाभ हैं:
- यह परीक्षण की प्रभावशीलता को मापने में सहायक होता है।
- यह घटकों और सॉफ्टवेयर मॉड्यूल के बीच दोषों की सघनता को अलग करने में सहायक होता है।
- यह उन क्षेत्रों की पहचान करने में उपयोगी है जिनमें सुधार या संशोधन की आवश्यकता है।
- यह उच्च जोखिम वाले घटकों की ओर इशारा करने में उपयोगी है, जो सीधे तौर पर इसमें योगदान देता है। जोखिम-आधारित परीक्षण.
- यह विभिन्न संसाधनों की प्रशिक्षण आवश्यकताओं की पहचान करने में सहायक होता है।
- यह दोषों के कारण होने वाले परीक्षण और पुनर्कार्य प्रयासों का अनुमान लगाने में सहायक हो सकता है।
- यह सॉफ्टवेयर में शेष दोषों का अनुमान लगा सकता है।
- रिलीज से पहले, यह निर्धारित करने में मदद करता है कि अब तक किए गए परीक्षण पर्याप्त हैं या नहीं।
- यह एक ऐतिहासिक आधार रेखा तैयार करता है जिसके आधार पर बाद में जारी किए जाने वाले संस्करणों का मूल्यांकन किया जा सकता है।
दोष घनत्व की सीमाएँ
इस मीट्रिक की गणना करना आसान है, लेकिन इसे गलत समझना भी आसान है। रिलीज़ संबंधी निर्णय में इसे कितना महत्व दिया जाना चाहिए, यह निम्नलिखित सीमाओं पर निर्भर करता है:
- जिन दोषों का पता नहीं चलता वे अदृश्य होते हैं। अंश में केवल वे दोष शामिल होते हैं जिन्हें परीक्षण में वास्तव में पाया गया है, इसलिए कम परीक्षण किया गया मॉड्यूल एक बेहतर आंकड़ा प्रस्तुत करता है।
- गंभीरता को नजरअंदाज किया जाता है। एक दोष जो भुगतान को बाधित करता है और एक कॉस्मेटिक संरेखण संबंधी समस्या, दोनों को समान महत्व दिया जाता है, यही कारण है कि इसके साथ-साथ गंभीरता-भारित दृष्टिकोण की आवश्यकता होती है।
- दोष की परिभाषाएँ भिन्न-भिन्न होती हैं। दो टीमें अलग-अलग तरीके से गिनती करती हैं तो उनसे प्राप्त संख्याएँ ऐसी होती हैं जिनकी तुलना नहीं की जा सकती, यहाँ तक कि एक ही संगठन के भीतर भी नहीं।
- कोड की पंक्तियाँ एक कमजोर आकार का प्रॉक्सी हैं। विस्तृत कोड से घनत्व कम हो जाता है लेकिन कुछ भी बेहतर नहीं होता, और यह इकाई विभिन्न प्रोग्रामिंग भाषाओं में तुलनीय नहीं है।
- इस मापदंड में हेरफेर किया जा सकता है। सीमावर्ती रिपोर्टों को खारिज करना या लाइन काउंट को बढ़ा-चढ़ाकर बताना, दोनों ही आंकड़े को बेहतर बनाते हैं लेकिन उत्पाद को बेहतर नहीं बनाते।
इन सब बातों से डिफेक्ट डेंसिटी बेकार नहीं हो जाती। बल्कि यह एक ऐसा ट्रेंड इंडिकेटर है जिसे लगातार मापे जाने वाले किसी एक उत्पाद के लिए इस्तेमाल किया जाता है, न कि टीमों की आपस में तुलना करने के लिए एक स्कोर के रूप में।
दोष घनत्व को कैसे कम करें
कागज़ पर नहीं, बल्कि वास्तव में दोष घनत्व को कम करने का अर्थ है दोषों को पहले ही रोकना और रिलीज़ से पहले बाकी दोषों का पता लगाना। नीचे दी गई पद्धतियाँ प्रकाशित दिशा-निर्देशों में बार-बार दोहराई जाती हैं:
- टेस्टिंग को पहले शुरू करें। आवश्यकता और डिजाइन चरण में परीक्षकों को शामिल करने से अस्पष्टता को कोड बनने से पहले ही पकड़ लिया जाता है, क्योंकि कोड बनने के चरण में ही दोषों को दूर करना सबसे सस्ता होता है।
- Revमर्ज होने से पहले कोड देखें। सहकर्मी समीक्षा से तर्क संबंधी त्रुटियां, आवश्यकताओं को गलत तरीके से समझना और डिजाइन संबंधी खामियां पकड़ी जाती हैं जिन्हें कोई अन्य समीक्षा नहीं पकड़ पाती। अध्याय परीक्षा खोजने के लिए लिखा गया था।
- रिग्रेशन सूट को स्वचालित करें। प्रत्येक कमिट पर जांच चलाना निरंतर एकीकरण नया कोड लिखते समय पुरानी खामियों को वापस आने से रोकता है।
- पहले टेस्ट लिखें। परीक्षण संचालित विकास प्रत्येक व्यवहार को लागू करने से पहले निर्दिष्ट करना अनिवार्य है, और उत्परिवर्तन परीक्षण इसके बाद, परिणामी परीक्षणों से प्राप्त निष्कर्षों की पुष्टि की जा सकती है।
- स्थैतिक विश्लेषण का प्रयोग करें। स्वचालित कोड स्कैनिंग किसी भी परीक्षण के चलने से पहले नल डीरेफरेंस, संसाधन लीक और जटिलता के हॉटस्पॉट को चिह्नित करता है।
- सघन मॉड्यूल को रिफैक्टर करें। एक बार डिफेक्ट डेंसिटी द्वारा सबसे खराब घटकों की पहचान हो जाने के बाद, उन्हें विभाजित और सरल बनाने से आमतौर पर जटिलता और दोषों की संख्या दोनों में कमी आती है।
- दोषपूर्ण तत्वों को वापस प्रक्रिया में शामिल करें। पिछली समीक्षाओं में मूल कारण विश्लेषण करने से व्यक्तिगत दोषों को एक बार के समाधान के बजाय प्रक्रियागत सुधारों में बदला जा सकता है।
Tracकेड रिलीज ओवर रिलीज साथ-साथ सॉफ्टवेयर परीक्षण तकनीक और कवरेज डेटा के साथ, दोष घनत्व एक रिपोर्ट कार्ड के बजाय एक प्रारंभिक चेतावनी प्रणाली बन जाता है।
