दोष-निर्धारण के लिए आवंटित कुल क्षमता का संतुलन प्रतिशत दोष इंजेक्शन दर के बराबर है ।
कई कारक इस दर को प्रभावित कर सकते हैं, उनमें से, ज़ाहिर है: टीम किस तरह का उत्पाद विकसित कर रही है, वे किन तकनीकों और तकनीकी प्रथाओं का उपयोग करते हैं, टीम के कौशल स्तर, कंपनी की संस्कृति, आदि।
टीम बी को ध्यान में रखते हुए, यदि वे अपने द्वारा पूरी की जाने वाली प्रत्येक 10 इकाइयों के लिए औसत 8 इकाइयों का निर्माण करते हैं, तो उन 8 इकाइयों के काम करने से नए 6.4 यूनिट्स का निर्माण होगा। हम कुल प्रयास का अनुमान लगा सकते हैं कि आखिरकार उन्हें ज्यामितीय प्रगति के योग के रूप में खर्च करना होगा:
10 + 8 + 6.4 + 5.12 + ...
समय के साथ बगों की संख्या में तेजी से कमी आएगी, लेकिन टीम बी में उनके घटक में ऐसा गुणांक है कि यह बहुत धीरे-धीरे शून्य हो जाएगा। दरअसल, उपरोक्त श्रृंखला में पहले तीन शब्दों का योग केवल 24.4 है; पहले पाँच में, 33.6; पहले 10, 45; पूरी श्रृंखला, 50. तो, टीम बी सारांश: दोष इंजेक्शन दर, 0.8; सुविधा विकास, 10/50 = 20%; दोष-निर्धारण, 80%। 20/80 उनकी स्थायी क्षमता आवंटन है।
इसके विपरीत, टीम ए ज्यादा बेहतर आकार में है। उनकी प्रगति इस तरह दिखती है:
40 + 10 + 2.5 + 0.625 + ...
इस श्रृंखला का योग 53 1/3 है, इसलिए टीम ए की सुविधा विकास आवंटन 40 / (53 1/3) = 75% है और दोष-निर्धारण आवंटन 25% है, जो कि उनके दोष इंजेक्शन दर 10/40 = 0.25 से मेल खाता है ।
दरअसल, पहले तीन के बाद टीम ए की श्रृंखला के सभी शब्द लापरवाही से छोटे हैं। व्यावहारिक अर्थों में इसका मतलब यह है कि टीम ए शायद रखरखाव के एक जोड़े के साथ अपने सभी कीड़े को स्क्वाश कर सकती है, दूसरा रिलीज काफी छोटा है। इससे एक भ्रम भी पैदा होता है कि कोई भी टीम ऐसा कर सकती है। लेकिन टीम बी नहीं।
मैंने डेविड एंडरसन की नई किताब "कानबन" को पढ़ते हुए इस समानता के बारे में सोचा । (पुस्तक एक अलग विषय पर है, लेकिन गुणवत्ता की चिंताओं को भी संबोधित करती है।) जब सॉफ्टवेयर की गुणवत्ता पर चर्चा की जाती है , तो कैपर्स जोन्स द्वारा एंडरसन ने इस पुस्तक को उद्धृत किया, "सॉफ्टवेयर आकलन, बेंचमार्क और सर्वश्रेष्ठ आचरण" :
"... 2000 में ... उत्तर अमेरिकी टीमों के लिए सॉफ्टवेयर की गुणवत्ता को मापा ... प्रति फ़ंक्शन 6 बिंदु से कम से कम 3 प्रति 100 फ़ंक्शन बिंदुओं तक कम, 200 से 1. की सीमा । मिडपॉइंट लगभग 1 दोष प्रति है 0.6 से 1.0 फंक्शन पॉइंट्स। इसका तात्पर्य यह है कि टीमों के लिए 90 प्रतिशत से अधिक खर्च करने के लिए आम है कि वे अपने प्रयासों के दोषों को ठीक कर सकें। " ।
जिस धारिता के साथ एंडरसन दोष इंजेक्शन दर से डिफिक्स-फिक्सिंग क्षमता आवंटन ( विफलता की मांग की अवधि है) के लिए चला जाता है यह बताता है कि दो चीजों की समानता सॉफ्टवेयर गुणवत्ता शोधकर्ताओं के लिए अच्छी तरह से जानी जाती है और शायद कुछ समय के लिए जाना जाता है। ।
तर्क की पंक्ति में प्रमुख शब्द जो मैं यहां प्रस्तुत करने की कोशिश कर रहा हूं, वे हैं "ईक्यूलीब्रियम" और "टिकाऊ"। यदि हम स्थिरता को दूर करते हैं, तो इन नंबरों को धोखा देने का एक स्पष्ट तरीका है: आप प्रारंभिक कोडिंग करते हैं, फिर कोड को कहीं और स्थानांतरित करते हैं, और दूसरों को रखरखाव छोड़ते हैं। या आप तकनीकी ऋण को चलाते हैं और इसे एक नए मालिक पर उतार देते हैं।
जाहिर है, कोई विशेष आवंटन सभी टीमों के अनुरूप नहीं होगा। अगर हम यह तय करते हैं कि 20% कीड़ों पर खर्च किया जाना चाहिए, तो, यदि किसी टीम में अल्ट्रा-लो दोष इंजेक्शन दर है, तो उनके पास समय को भरने के लिए पर्याप्त कीड़े नहीं होंगे, और यदि टीम में बहुत अधिक दर थी, तो उनके कीड़े जमा होता रहेगा।
मैंने यहां जो गणित प्रयोग किया है, वह सरल है। मैंने लेन-देन की लागत (योजना और अनुमान बैठक, पोस्ट-मॉर्टम, आदि) जैसी चीजों की उपेक्षा की, जो प्रतिशत को कुछ हद तक प्रभावित करेगा। मैंने एक उत्पाद को बनाए रखने और एक दूसरे को समवर्ती रूप से विकसित करने के समीकरणों को छोड़ दिया। लेकिन निष्कर्ष अभी भी खड़ा है। तकनीकी दोष, यूनिट-परीक्षण, निरंतर एकीकरण, कोड समीक्षा, आदि के संदर्भ में, अपने दोष इंजेक्शन दर को कम करने के लिए और, परिणामस्वरूप, आपकी विफलता की मांग के अनुसार आप क्या कर सकते हैं। यदि आप प्रत्येक 10 सुविधाओं के लिए केवल एक बग बना सकते हैं, तो आपके पास नई सुविधाओं को विकसित करने और अपने ग्राहकों को संतुष्ट करने के लिए बहुत खाली समय होगा।