2.11 सॉफ़्टवेयर गुणवत्ता

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

• गुणवत्ता उद्देश्य के लिए उपयुक्तता जमा आवश्यकताओं के अनुपालन है; दोनों को स्पष्ट रूप से परिभाषित करें।
• गुणवत्ता निर्मित की जाती है, टेस्ट करके प्राप्त नहीं की जाती; सत्यापन दोष खोजता है, लेकिन रोकथाम उन्हें टालती है।
• गुणवत्ता आश्वासन (क्या हमारी प्रक्रियाएँ सुदृढ़ हैं?) को गुणवत्ता नियंत्रण (क्या यह उत्पाद अच्छा है?) से अलग करें।
• सत्यापन (verification) पूछता है “क्या हमने इसे सही बनाया?”; वैधीकरण (validation) पूछता है “क्या हमने सही चीज़ बनाई?”
• गुणवत्ता को अर्थपूर्ण मेट्रिक्स के एक छोटे समूह से मापें; मेट्रिक्स को संकेत मानें, लक्ष्य नहीं।
• किसी दोष की लागत जितनी देर से मिलता है उतनी बढ़ती जाती है, इसलिए गुणवत्ता गतिविधियों को पहले की ओर खिसकाएँ।
• गुणवत्ता पूरे संगठन और उसकी संस्कृति का एक गुण है, अंत में लगा कोई गेट नहीं।

सिफ़ारिशें

ISO/IEC 25010 जैसा एक साझा गुणवत्ता मॉडल अपनाएँ

अपने संगठन को एक मान्यता प्राप्त उत्पाद-गुणवत्ता मॉडल अपनाकर गुणवत्ता के लिए एक साझा शब्दावली दें। ISO/IEC 25010 कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, उपयोगिता, विश्वसनीयता, सुरक्षा, अनुरक्षणीयता, और पोर्टेबिलिटी सहित विशेषताओं को परिभाषित करता है। इसका उपयोग गुणवत्ता को ठोस बनाने के लिए करें: हर सिस्टम के लिए तय करें कि कौन-सी विशेषताएँ सबसे अधिक मायने रखती हैं और हर एक के लिए “पर्याप्त रूप से अच्छा” का क्या अर्थ है। ये उत्पाद-गुणवत्ता विशेषताएँ वही गुणवत्ता गुण (quality attributes) हैं जो आर्किटेक्चर (अध्याय 3.1) को चलाते हैं। गुणवत्ता और आर्किटेक्चर एक ही सरोकार के दो दृष्टिकोण हैं, इसलिए उन्हें दो प्रतिस्पर्धी सूचियों के बजाय प्राथमिकताओं की एक सूची साझा करने दें।

गुणवत्ता आश्वासन को गुणवत्ता नियंत्रण से अलग करें

गुणवत्ता आश्वासन (QA) और गुणवत्ता नियंत्रण (QC) को अलग लेकिन पूरक गतिविधियों के रूप में लें। QA प्रक्रिया-उन्मुख और निवारक है: यह मानकों, समीक्षाओं, डन की परिभाषाओं, और प्रशिक्षण के माध्यम से काम करने के तरीके को सुधारता है, ताकि दोषों के शुरू में ही आने की संभावना कम हो। QC उत्पाद-उन्मुख और खोजी है: यह वास्तविक कार्य-उत्पादों का निरीक्षण करता है, जैसे टेस्टिंग, कोड समीक्षा, और ऑडिट, ताकि वे दोष पकड़े जाएँ जो अंदर आ ही गए। एक परिपक्व संगठन दोनों में निवेश करता है, लेकिन QA की ओर झुकता है, क्योंकि दोषों को रोकना उन्हें खोजने और ठीक करने से सस्ता है।

स्पष्ट सॉफ़्टवेयर गुणवत्ता प्रबंधन प्रक्रियाएँ चलाएँ

गुणवत्ता को एक प्रबंधित प्रक्रिया बनाएँ, कोई चुप्पी उम्मीद नहीं। महत्वपूर्ण काम के लिए, एक गुणवत्ता योजना लिखें जो लक्षित गुणवत्ता विशेषताओं, आश्वासन और नियंत्रण गतिविधियों, स्वीकृति मानदंडों, और कौन जवाबदेह है यह बताए। इसे उन प्रथाओं में बुनें जो आपके पास पहले से हैं: कोड समीक्षा (अध्याय 2.5) एक नियंत्रण और ज्ञान साझा करने के तरीके दोनों के रूप में, टेस्टिंग रणनीति (अध्याय 2.4) स्वचालित सुरक्षा जाल के रूप में, और स्टैटिक एनालिसिस निरंतर निरीक्षण के रूप में। गुणवत्ता डेटा की नियमित समीक्षा करें और रुझानों पर कार्रवाई करें, न कि केवल घटनाओं पर प्रतिक्रिया दें।

सत्यापन और वैधीकरण को अलग-अलग अनुशासन के रूप में अभ्यास करें

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

अर्थपूर्ण मेट्रिक्स से गुणवत्ता को मापें

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

दोषों को व्यवस्थित रूप से चरित्रांकित और प्रबंधित करें

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

गुणवत्ता की लागत को जानबूझकर प्रबंधित करें

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

एक गुणवत्ता संस्कृति बनाएँ

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

प्रथा / विकल्प	फ़ायदे	नुकसान
औपचारिक गुणवत्ता मॉडल (ISO 25010)	साझा शब्दावली; स्पष्ट प्राथमिकताएँ	कट्टरता से लागू करने पर ओवरहेड
भारी गुणवत्ता आश्वासन (रोकथाम)	कम दोष; कम कुल लागत	पहले से निवेश; भुगतान दिखने में धीमा
भारी गुणवत्ता नियंत्रण (निरीक्षण)	निकल गए दोषों को पकड़ता है	महँगा; दोष देर से मिलते हैं
स्वतंत्र V&V	उच्च आश्वासन; वस्तुनिष्ठ	महँगा; धीमा; विरोधी जैसा महसूस हो सकता है
समृद्ध गुणवत्ता मेट्रिक्स	दृश्यता; शुरुआती चेतावनी	हेरफेर का जोखिम; मापन ओवरहेड
समर्पित QA टीम	केंद्रित ध्यान और विशेषज्ञता	डेवलपरों से ज़िम्मेदारी हटा सकती है
टीमों के स्वामित्व वाली गुणवत्ता	स्वामित्व; तेज़ फ़ीडबैक	हर जगह अनुशासन और कौशल चाहिए

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

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

2. क्या हमारी टीम में किसी दोष या निकट-चूक की रिपोर्ट करना सुरक्षित है, और जो व्यक्ति इसे उठाता है उसके साथ क्या होता है? गुणवत्ता संस्कृति का एक गुण है, और एक दोषरहित दृष्टिकोण समस्याओं को जल्दी खुले में लाता है जबकि एक दोष मढ़ने वाला दृष्टिकोण उन्हें तब तक छुपाता है जब तक वे महँगी न हो जाएँ, जो किसी विनियमित या नागरिक-सामना करने वाले सिस्टम में एक सार्वजनिक विफलता या दंड का मतलब हो सकता है। यह बड़े पैमाने पर सबसे अधिक मायने रखता है, जहाँ किसी जोखिम के सबसे करीब का इंजीनियर अक्सर जूनियर होता है और चुप रहने की प्रेरणा प्रबल होती है। ईमानदार संकेत लाएँ: क्या निकट-चूकें लॉग और चर्चा की जाती हैं, या वे गायब हो जाती हैं? क्या पोस्टमॉर्टम कारणों का नाम लेते हैं या लोगों का? कार्रवाई है गुणवत्ता डेटा को डंडे के बजाय एक सीखने के उपकरण के रूप में लेना, जो लोग समस्याएँ सामने लाते हैं उन्हें पुरस्कृत करना, और दोषरहित पोस्टमॉर्टम चलाना, क्योंकि आप उसे नहीं रोक सकते जिसकी रिपोर्ट करने से आपकी टीम डरती है।

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

4. क्या हम वाकई अपनी खराब गुणवत्ता की लागत जानते हैं, और क्या हम जानबूझकर खर्च को विफलता से रोकथाम की ओर खिसका रहे हैं? खराब गुणवत्ता की लागत (COPQ) वह पैसा है जो आंतरिक पुनर्कार्य, उत्पादन घटनाओं, आपातकालीन फिक्सों, सपोर्ट भार, खोए हुए उपयोगकर्ताओं, और दंडों में खोया जाता है, और यह लगभग हमेशा समीक्षाओं और टेस्टिंग पर दिखने वाले खर्च से बड़ा होता है। किसी बड़ी टीम में विफलता लागतें घटना चैनलों, सपोर्ट कतारों, और उस पुनर्कार्य में बिखरी होती हैं जिसे कोई पुनर्कार्य के रूप में लॉग नहीं करता, इसलिए वे तब तक अदृश्य रहती हैं जब तक कोई उन्हें जोड़ न ले। तनाव यह है कि रोकथाम अभी, एक बजट चक्र में पैसा खर्च करवाती है ताकि उन विफलता लागतों से बचा जाए जो बाद में आती हैं और किसी और के बजट पर पड़ती हैं, जो इस व्यापार को हमेशा के लिए टालना आसान बना देता है। वास्तविक आँकड़े लाएँ: घटना गिनती और लागत, पुनर्कार्य घंटे, पलायन-दोष दर, और रोकथाम, मूल्यांकन, और विफलता में खर्च का वर्तमान बँटवारा, फिर तय करें कि मिश्रण को पहले की ओर बढ़ना चाहिए या नहीं। एंटरप्राइज़ और सरकारी सिस्टमों के लिए, जहाँ अधिकांश जीवनकाल लागत पहली रिलीज़ के बाद आती है, COPQ को उन लोगों के सामने रखें जो बजट रखते हैं, क्योंकि जो संख्या कोई निगरानी निकाय देख सकती है उसे “गुणवत्ता” के लिए किसी अस्पष्ट अपील की तुलना में टालना कहीं अधिक कठिन है।

5. हमारे कौन से गुणवत्ता मेट्रिक्स चुपचाप लक्ष्य बन गए हैं, और वे अब कौन-सा व्यवहार चला रहे हैं? कोई मेट्रिक जो लक्ष्य बन जाता है वास्तविकता को मापना बंद कर देता है: कवरेज प्रतिशत का पीछा करें और आपको ऐसे टेस्ट मिलते हैं जो संख्या हिलाने के लिए लिखे गए हैं, दोष पकड़ने के लिए नहीं। बड़े पैमाने पर यह खतरनाक है, क्योंकि दर्जनों टीमों में साझा एक हेडलाइन डैशबोर्ड उन सबके लिए प्रोत्साहन तय कर देता है, और एक हेरफेर-योग्य मेट्रिक हेरफेर को हर जगह एक साथ फैला देता है। प्रतिस्पर्धी विचार यह है कि आपको अभी भी मापन चाहिए, इसलिए उत्तर शायद ही कभी “मेट्रिक हटा दें” होता है बल्कि “इसे एक प्रति-संकेत के साथ जोड़ें और समीक्षाओं तथा उपयोगकर्ताओं के गुणात्मक प्रमाण के साथ पढ़ें” होता है। अपना वर्तमान मेट्रिक सेट लाएँ और हर एक के लिए पूछें कि दबाव में कोई व्यक्ति गुणवत्ता सुधारे बिना इसे हिलाने के लिए क्या कर सकता है, और क्या आपने ऐसा होते देखा है। विनियमित और नागरिक-सामना करने वाले परिवेशों में, विशेष रूप से उन अनुपालन मेट्रिक्स से सावधान रहें जो हरे दिखते हैं जबकि अंतर्निहित वैधीकरण (एक्सेसिबिलिटी, वास्तविक उपयोगकर्ता परिणाम) कभी वास्तव में परखा ही नहीं गया, क्योंकि कोई ऑडिटर अंततः संख्या के पीछे की वास्तविकता का परीक्षण करेगा।

6. यहाँ गुणवत्ता का स्वामी कौन है: वे टीमें जो कोड लिखती हैं, या अंत में एक अलग समूह, और हम वास्तव में किसके लिए संसाधन दे रहे हैं? स्वामित्व नीचे की हर चीज़ को आकार देता है, क्योंकि एक डाउनस्ट्रीम QA साइलो डेवलपरों को उनके लिखे कोड की ज़िम्मेदारी उतारने देता है, जबकि टीम-स्वामित्व वाली गुणवत्ता हर टीम में कौशल और अनुशासन की माँग की कीमत पर स्वामित्व बनाती है। किसी बड़ी टीम में यह या-या नहीं है: टिकाऊ प्रतिरूप आमतौर पर होता है टीमें कोड समीक्षा और स्वचालित टेस्टों के माध्यम से गुणवत्ता का स्वामित्व रखें, एक छोटे केंद्रीय समूह के समर्थन से जो मानकों को बनाए रखता है, गुणवत्ता आश्वासन को प्रक्रिया सुधार के रूप में चलाता है, और कोचिंग करता है, न कि अंत में गुणवत्ता का निरीक्षण करना। एक ईमानदार नक्शा लाएँ कि गुणवत्ता काम वर्तमान में कहाँ होता है, जब कोई दोष निकल जाता है तो कौन जवाबदेह है, और बजट तथा हेडकाउंट वास्तव में कहाँ बैठते हैं बनाम बयानबाज़ी कहाँ कहती है कि गुणवत्ता रहती है। एंटरप्राइज़ और सरकारी संगठनों के लिए, स्वतंत्र सत्यापन और वैधीकरण आवश्यकता जोड़ें: कुछ आश्वासन शासन एक अलग पक्ष को अनिवार्य करते हैं, इसलिए जानबूझकर तय करें कि कौन-से नियंत्रण डिलीवरी टीमों के हैं और कौन-से ऑडिट को संतुष्ट करने के लिए स्वतंत्र रहने चाहिए।

क्षेत्र-विशेष दृष्टिकोण

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

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

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

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

उदाहरण

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

एंटरप्राइज़। एक बड़ी वित्तीय-सेवा फ़र्म ISO/IEC 25010 को अपनी गुणवत्ता शब्दावली के रूप में अपनाती है और, हर उत्पाद के लिए, विश्वसनीयता, सुरक्षा, और अनुरक्षणीयता के लक्षित स्तर दर्ज करती है। टीमें गुणवत्ता का स्वामित्व रखती हैं: कोड समीक्षा और स्वचालित टेस्ट पाइपलाइन में नियंत्रण हैं, जबकि एक छोटा केंद्रीय समूह मानकों को बनाए रखकर और कोचिंग देकर QA चलाता है। एक गुणवत्ता डैशबोर्ड दोष-पलायन दर, परिवर्तन-विफलता दर, और कोड-स्वास्थ्य रुझानों को ट्रैक करता है। दोषों को वर्गीकृत किया जाता है और उनके मूल कारण खोजे जाते हैं, और दोहराए जाने वाले कारण साझा लाइब्रेरियों और चेकलिस्टों में अद्यतनों को चलाते हैं। नेतृत्व त्रैमासिक रूप से गुणवत्ता-लागत डेटा की समीक्षा करता है और खर्च को रोकथाम की ओर खिसका दिया है, जिससे उत्पादन घटनाएँ और उन्हें ठीक करने की लागत दोनों कम हुई हैं।

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

गुणवत्ता पर रिटर्न है कम कुल स्वामित्व लागत और स्थिर डिलीवरी गति। गुणवत्ता की लागत के दो पहलू हैं। अच्छा खर्च, रोकथाम और मूल्यांकन, दृश्यमान और नियंत्रणीय है: डिज़ाइन, मानक, समीक्षाएँ, टेस्टिंग, और टूलिंग। खराब गुणवत्ता की लागत (COPQ) बड़ी है लेकिन अक्सर छुपी होती है: आंतरिक पुनर्कार्य, उत्पादन घटनाएँ, आपातकालीन फिक्स, ग्राहक सपोर्ट, खोए हुए उपयोगकर्ता, नियामक दंड, और प्रतिष्ठा को नुकसान। Crosby के “Quality Is Free” तक जाने वाले अध्ययनों ने लगातार पाया है कि खराब गुणवत्ता की कुल लागत उसे रोकने की लागत को बौना बना देती है, और यह कि दोष जितनी देर से पकड़े जाते हैं उतने ही कहीं अधिक महँगे होते जाते हैं: डिज़ाइन में मिली कोई समस्या प्रोडक्शन में मिली उसी समस्या की तुलना में एक अंश जितनी ही लागत रखती है।

नेतृत्व के लिए, तर्क यह नहीं है “गुणवत्ता पर अधिक खर्च करें।” यह है “कुल मिलाकर कम खर्च करने के लिए पहले खर्च करें।” अपने ही डेटा (घटना गिनती और लागत, पुनर्कार्य घंटे, पलायन-दोष दर) से COPQ को परिमाणित करें और दिखाएँ कि रोकथाम और शुरुआती मूल्यांकन इसे कैसे कम लाते हैं। गुणवत्ता को व्यावसायिक परिणामों से जोड़ें: विश्वसनीयता ग्राहकों को बनाए रखती है, अनुरक्षणीयता भविष्य के परिवर्तन को सस्ता रखती है, और सुरक्षा तथा एक्सेसिबिलिटी आपको कानूनी परेशानी से दूर रखती हैं। दीर्घजीवी एंटरप्राइज़ और सरकारी सिस्टमों में, जहाँ अधिकांश लागत पहली रिलीज़ के बाद आती है, गुणवत्ता के अनुरक्षणीयता और विश्वसनीयता आयाम जीवनकाल लागत पर हावी रहते हैं। यह शुरुआती गुणवत्ता निवेश को आपके द्वारा लिए जा सकने वाले सबसे अधिक लाभ वाले निर्णयों में से एक बनाता है।

एंटी-पैटर्न और नुकसान

• गुणवत्ता को अंतिम गेट के रूप में लेना: इसे बनाने के बजाय अंत में गुणवत्ता का निरीक्षण करना, ताकि दोष तब मिलें जब वे सबसे महँगे हों।
• टेस्टिंग को गुणवत्ता समझ लेना: यह मान लेना कि टेस्ट पास होने का मतलब उच्च गुणवत्ता है, अनुरक्षणीयता, उपयोगिता, और उद्देश्य के लिए उपयुक्तता को नज़रअंदाज़ करना।
• अलग साइलो के रूप में QA: एक डाउनस्ट्रीम टीम जो “गुणवत्ता की स्वामी” है, जो डेवलपरों को उनके लिखे कोड की ज़िम्मेदारी उतारने देती है।
• मेट्रिक्स का प्रदर्शन: कवरेज प्रतिशत या दोष गिनती को लक्ष्य के रूप में पीछा करना, जो हेरफेर को आमंत्रित करता है और असली गुणवत्ता छुपाता है।
• वैधीकरण के बिना सत्यापन: विनिर्देश को सही ढंग से बनाना जबकि कभी यह जाँच न करना कि विनिर्देश वास्तविक ज़रूरतों को पूरा करता है या नहीं।
• कोई मूल-कारण विश्लेषण नहीं: व्यवस्थागत कारण को संबोधित किए बिना दोषों को व्यक्तिगत रूप से ठीक करना, ताकि वही वर्ग दोहराया जाए।
• खराब गुणवत्ता की लागत को नज़रअंदाज़ करना: गुणवत्ता को शुद्ध लागत मानना क्योंकि विफलता लागतें छुपी और अमापित हैं।

परिपक्वता मॉडल

स्तर 1 (आरंभ)। गुणवत्ता अपरिभाषित और तदर्थ है। यह व्यक्तिगत परिश्रम पर सवार होती है, मुख्यतः अंत में मैनुअल टेस्टिंग द्वारा जाँची जाती है, और दोषों को सामने आते ही प्रतिक्रियात्मक रूप से संभाला जाता है। कोई साझा मॉडल नहीं है, कोई मेट्रिक्स नहीं है, और आश्वासन तथा नियंत्रण के बीच कोई रेखा नहीं है।

स्तर 2 (विकास)। बुनियादी प्रथाएँ दिखती हैं: कोड समीक्षा, स्वचालित टेस्ट, और एक दोष ट्रैकर। कुछ गुणवत्ता डेटा इकट्ठा किया जाता है, लेकिन असमान रूप से, और हर टीम इसे अपने तरीके से करती है। गुणवत्ता को अभी भी अधिकांशतः टेस्टिंग के रूप में देखा जाता है, रोकथाम न्यूनतम है, सत्यापन होता है, और वैधीकरण अनौपचारिक है।

स्तर 3 (मानकीकरण)। संगठन एक साझा गुणवत्ता मॉडल (जैसे ISO/IEC 25010) अपनाता है, QA को QC से अलग करता है, और गुणवत्ता योजनाओं और स्वीकृति मानदंडों के साथ गुणवत्ता प्रबंधन प्रक्रियाएँ चलाता है, जो दस्तावेज़ीकृत हैं और टीमों में लगातार लागू होती हैं। सत्यापन और वैधीकरण अलग-अलग और जानबूझकर हैं, और दोषों को एक सहमत योजना के अनुसार वर्गीकृत और मूल-कारण खोजा जाता है।

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

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

चर्चा के लिए विचार

• आपके सिस्टमों के लिए कौन-सी ISO/IEC 25010 गुणवत्ता विशेषताएँ सबसे अधिक मायने रखती हैं, और हर एक के लिए “पर्याप्त रूप से अच्छा” क्या है?
• आपका संगठन रोकथाम-मूल्यांकन-विफलता खर्च मिश्रण में कहाँ बैठता है, और क्या इसे बदलना चाहिए?
• क्या आप व्यवहार में सत्यापन को वैधीकरण से अलग करते हैं, या दोनों को “टेस्टिंग” में समेट देते हैं?
• क्या गुणवत्ता का स्वामित्व सॉफ़्टवेयर बनाने वाली टीमों के पास है, या किसी अलग समूह को सौंपा गया है, और यदि आप इसे बदलें तो क्या बदलेगा?
• खराब गुणवत्ता की आपकी वास्तविक लागत क्या है, और क्या आप व्यावसायिक मामला बनाने लायक अच्छी तरह इसे माप सकते हैं?
• आपके कौन-से गुणवत्ता मेट्रिक्स वास्तविक संकेत हैं, और कौन-से हेरफेर-योग्य लक्ष्य बन गए हैं?

मुख्य निष्कर्ष

• गुणवत्ता टेस्टिंग से कहीं व्यापक है: यह विश्वसनीयता, सुरक्षा, और अनुरक्षणीयता जैसी विशेषताओं में उद्देश्य के लिए उपयुक्तता जमा अनुपालन है।
• एक साझा गुणवत्ता मॉडल (ISO/IEC 25010) का उपयोग करें ताकि गुणवत्ता गुण स्पष्ट हों और आर्किटेक्चर (अध्याय 3.1) के साथ संरेखित हों।
• गुणवत्ता आश्वासन (रोकथाम, प्रक्रिया) को गुणवत्ता नियंत्रण (पहचान, उत्पाद) से अलग करें, और रोकथाम की ओर झुकें।
• सत्यापन (इसे सही बनाया) और वैधीकरण (सही चीज़ बनाई) को अलग-अलग अनुशासन के रूप में अभ्यास करें।
• गुणवत्ता को कुछ अर्थपूर्ण मेट्रिक्स से मापें, और पुनरावृत्ति रोकने के लिए दोषों को गंभीरता और मूल कारण के अनुसार चरित्रांकित करें।
• गुणवत्ता की लागत प्रबंधित करें: रोकथाम और शुरुआती मूल्यांकन विफलता से कहीं सस्ते हैं, विशेष रूप से दीर्घजीवी सिस्टमों में।
• कोड समीक्षा (अध्याय 2.5) और टेस्टिंग रणनीति (अध्याय 2.4) के समर्थन से एक दोषरहित गुणवत्ता संस्कृति बनाएँ जहाँ टीमें गुणवत्ता का स्वामित्व रखें।

संदर्भ और आगे पढ़ने के लिए

• IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Quality knowledge area.
• ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models.
• ISO/IEC 25000 series (SQuaRE), Software product quality requirements and evaluation.
• Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain.
• W. Edwards Deming, Out of the Crisis.
• Capers Jones and Olivier Bonsignour, The Economics of Software Quality.
• Gerald Weinberg, Quality Software Management.
• ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (गुणवत्ता आश्वासन और V&V प्रक्रिया संदर्भ)।