Software quality
सॉफ्टवेयर इंजीनियरिंग के संदर्भ में, सॉफ्टवेयर की गुणवत्ता दो संबंधित लेकिन अलग-अलग धारणाओं को संदर्भित करती हैः सॉफ्टवेयर की कार्यात्मक गुणवत्ता दर्शाती है कि यह कार्यात्मक आवश्यकताओं या विनिर्देशों के आधार पर किसी दिए गए डिजाइन के साथ कितनी अच्छी तरह से अनुपालन करता है या उसके अनुरूप है। उस विशेषता को सॉफ्टवेयर के एक टुकड़े के उद्देश्य के लिए योग्यता के रूप में भी वर्णित किया जा सकता है या यह एक सार्थक उत्पाद के रूप में बाजार में प्रतियोगियों से कैसे तुलना करता है। यह वह डिग्री है जिस पर सही सॉफ्टवेयर का उत्पादन किया गया था। सॉफ्टवेयर संरचनात्मक गुणवत्ता से तात्पर्य है कि यह कैसे गैर-कार्यात्मक आवश्यकताओं को पूरा करता है जो कार्यात्मक आवश्यकताओं के वितरण का समर्थन करते हैं, जैसे कि मजबूती या रखरखाव। सॉफ्टवेयर आवश्यकता के अनुसार किस हद तक काम करता है, इसके साथ इसका बहुत कुछ लेना-देना है। संरचनात्मक गुणवत्ता के कई पहलुओं का मूल्यांकन केवल सॉफ्टवेयर आंतरिक संरचना, इसके स्रोत कोड (सॉफ्टवेयर मेट्रिक्स देखें), इकाई स्तर पर और प्रणाली स्तर (कभी-कभी अंत से अंत परीक्षण के रूप में संदर्भित) के विश्लेषण के माध्यम से किया जा सकता है, जो प्रभावी रूप से है कि इसकी वास्तुकला ऑब्जेक्ट मैनेजमेंट ग्रुप (ओ. एम. जी.) द्वारा विषय पर एक पेपर में उल्लिखित सॉफ्टवेयर वास्तुकला के ध्वनि सिद्धांतों का पालन करती है। हालांकि कुछ संरचनात्मक गुणों, जैसे कि उपयोगिता, का मूल्यांकन केवल गतिशील रूप से किया जा सकता है (उपयोगकर्ता या उनकी ओर से काम करने वाले अन्य लोग सॉफ्टवेयर के साथ बातचीत करते हैं या, कम से कम, कुछ प्रोटोटाइप या आंशिक कार्यान्वयन; यहां तक कि कार्डबोर्ड में बने नकली संस्करण के साथ बातचीत भी एक गतिशील परीक्षण का प्रतिनिधित्व करती है क्योंकि इस तरह के संस्करण को एक प्रोटोटाइप माना जा सकता है)। अन्य पहलू, जैसे कि विश्वसनीयता, में न केवल सॉफ्टवेयर शामिल हो सकता है, बल्कि अंतर्निहित हार्डवेयर भी शामिल हो सकता है, इसलिए, इसका मूल्यांकन स्थिर और गतिशील दोनों तरह से किया जा सकता है (तनाव परीक्षण)। कार्यात्मक गुणवत्ता का मूल्यांकन आमतौर पर गतिशील रूप से किया जाता है लेकिन स्थिर परीक्षणों (जैसे सॉफ्टवेयर समीक्षा) का उपयोग करना भी संभव है। ऐतिहासिक रूप से, सॉफ्टवेयर गुणवत्ता प्रबंधन के लिए लागू विशेषताओं और मेट्रिक्स की संरचना, वर्गीकरण और शब्दावली को आईएसओ 9126 और बाद के आईएसओ/आईईसी 25000 मानक से प्राप्त या निकाला गया है। इन मॉडलों के आधार पर (मॉडल देखें), कंसोर्टियम फॉर आईटी सॉफ्टवेयर क्वालिटी (सी. आई. एस. क्यू.) ने व्यावसायिक मूल्य प्रदान करने के लिए सॉफ्टवेयर के एक टुकड़े के लिए आवश्यक पांच प्रमुख वांछनीय संरचनात्मक विशेषताओं को परिभाषित किया हैः विश्वसनीयता, दक्षता, सुरक्षा, रखरखाव और (पर्याप्त) आकार। सॉफ्टवेयर गुणवत्ता मापन इन पाँच आयामों में से प्रत्येक के साथ एक सॉफ्टवेयर प्रोग्राम या सिस्टम दर किस हद तक निर्धारित करता है। सॉफ्टवेयर गुणवत्ता के एक समग्र माप की गणना एक गुणात्मक या मात्रात्मक स्कोरिंग योजना या दोनों के मिश्रण और फिर प्राथमिकताओं को दर्शाने वाली एक भार प्रणाली के माध्यम से की जा सकती है। सॉफ्टवेयर गुणवत्ता के एक रैखिक निरंतरता पर स्थित होने के इस दृष्टिकोण को "महत्वपूर्ण प्रोग्रामिंग त्रुटियों" के विश्लेषण द्वारा पूरक किया जाता है जो विशिष्ट परिस्थितियों में विनाशकारी आउटेज या प्रदर्शन गिरावट का कारण बन सकते हैं जो समग्र मापों के आधार पर रेटिंग की परवाह किए बिना किसी दिए गए सिस्टम को उपयोग के लिए अनुपयुक्त बनाते हैं। प्रणाली स्तर पर पाई जाने वाली इस तरह की प्रोग्रामिंग त्रुटियां 90 प्रतिशत उत्पादन समस्याओं का प्रतिनिधित्व करती हैं, जबकि इकाई स्तर पर, भले ही बहुत अधिक हों, प्रोग्रामिंग त्रुटियां उत्पादन मुद्दों के 10 प्रतिशत से भी कम के लिए जिम्मेदार होती हैं (नब्बे-नब्बे नियम भी देखें)। नतीजतन, पूरी प्रणाली के संदर्भ के बिना कोड की गुणवत्ता, जैसा कि डब्ल्यू. एडवर्ड्स डेमिंग ने इसका वर्णन किया है, का सीमित मूल्य है। सॉफ्टवेयर की गुणवत्ता माप, अवधारणाओं और सूचना दृश्य की तकनीकों को देखने, तलाशने, विश्लेषण करने और संवाद करने के लिए दृश्य, संवादात्मक साधन उपयोगी होते हैं, विशेष रूप से, यदि कई सॉफ्टवेयर गुणवत्ता उपायों को एक दूसरे से या किसी सॉफ्टवेयर या प्रणाली के घटकों से संबंधित होना है। उदाहरण के लिए, सॉफ्टवेयर मानचित्र एक विशेष दृष्टिकोण का प्रतिनिधित्व करते हैं जो "सॉफ्टवेयर विकास, सॉफ्टवेयर गुणवत्ता और सिस्टम गतिशीलता के बारे में जानकारी को व्यक्त और जोड़ सकता है।" सॉफ्टवेयर गुणवत्ता भी एक सॉफ्टवेयर परियोजना के विमोचन चरण में एक भूमिका निभाती है। विशेष रूप से, रिलीज प्रक्रियाओं की गुणवत्ता और स्थापना (पैच प्रक्रियाएं भी), विन्यास प्रबंधन एक समग्र सॉफ्टवेयर इंजीनियरिंग प्रक्रिया के महत्वपूर्ण भाग हैं। प्रेरणा सॉफ्टवेयर की गुणवत्ता कम से कम दो मुख्य दृष्टिकोणों से प्रेरित होती हैः जोखिम प्रबंधनः सॉफ्टवेयर की विफलता असुविधा से अधिक का कारण बनी है। सॉफ्टवेयर त्रुटियाँ मानव मृत्यु का कारण बन सकती हैं (उदाहरण के लिए सॉफ्टवेयर बग्स की सूची देखें)। इसके कारण खराब रूप से डिज़ाइन किए गए उपयोगकर्ता इंटरफेस से लेकर प्रत्यक्ष प्रोग्रामिंग त्रुटियों तक हैं, उदाहरण के लिए बोइंग 737 मामले या अनपेक्षित त्वरण मामले या थेरैक-25 मामले देखें। इसके परिणामस्वरूप कुछ प्रकार के सॉफ़्टवेयर के विकास की आवश्यकताएँ, विशेष रूप से और ऐतिहासिक रूप से चिकित्सा और अन्य उपकरणों में एम्बेडेड सॉफ़्टवेयर के लिए जो महत्वपूर्ण बुनियादी ढांचे को नियंत्रित करते हैंः "[इंजीनियर जो एम्बेडेड सॉफ़्टवेयर लिखते हैं] कचरा संग्रह करने और उपयोगकर्ता इंटरफेस को अद्यतन करने के लिए जावा प्रोग्राम को एक सेकंड के एक तिहाई के लिए रुकते हुए देखते हैं, और वे हवाई जहाज के आसमान से गिरने की कल्पना करते हैं।" संयुक्त राज्य अमेरिका में, संघीय विमानन प्रशासन (एफ. ए. ए.) के भीतर, एफ. ए. ए. विमान प्रमाणन सेवा सॉफ्टवेयर कार्यक्रम, नीति, मार्गदर्शन और प्रशिक्षण प्रदान करती है, सॉफ्टवेयर और जटिल इलेक्ट्रॉनिक हार्डवेयर पर ध्यान केंद्रित करती है जिसका हवाई उत्पाद पर प्रभाव पड़ता है (एक "उत्पाद" एक विमान, एक इंजन या एक प्रोपेलर है)। प्रमाणन मानक जैसे डी. ओ.-178सी, आई. एस. ओ. 26262, आई. ई. सी. 62304, आदि। मार्गदर्शन दें। लागत प्रबंधनः इंजीनियरिंग के किसी भी अन्य क्षेत्र की तरह, अच्छे सॉफ्टवेयर गुणवत्ता द्वारा नियंत्रित एक सॉफ्टवेयर उत्पाद या सेवा को बनाए रखने में कम लागत आती है, इसे समझना आसान होता है और दबाव वाली व्यावसायिक जरूरतों के जवाब में अधिक लागत प्रभावी हो सकता है। उद्योग डेटा दर्शाता है कि मुख्य व्यावसायिक अनुप्रयोगों (जैसे उद्यम संसाधन योजना (ई. आर. पी.), ग्राहक संबंध प्रबंधन (सी. आर. एम.) या वित्तीय सेवाओं में बड़ी लेनदेन प्रसंस्करण प्रणालियों) में खराब अनुप्रयोग संरचनात्मक गुणवत्ता के परिणामस्वरूप लागत, अनुसूची में वृद्धि होती है और पुनः कार्य के रूप में अपशिष्ट पैदा होता है (मुदा (जापानी शब्द) देखें)। इसके अलावा, खराब संरचनात्मक गुणवत्ता दूषित डेटा, अनुप्रयोग आउटेज, सुरक्षा उल्लंघनों और प्रदर्शन समस्याओं के कारण उच्च प्रभाव वाले व्यावसायिक व्यवधानों के साथ दृढ़ता से सहसंबद्ध है। खराब गुणवत्ता की लागत पर सी. आई. एस. क्यू. की रिपोर्ट का अनुमान हैः 2020 में $2.08 ट्रिलियन का प्रभाव, 2018 में $2.84 ट्रिलियन, आई. बी. एम. की डेटा उल्लंघन की लागत रिपोर्ट 2020 का अनुमान है कि डेटा उल्लंघन की औसत वैश्विक लागतः $3.86 लाख परिभाषाएँ आई. एस. ओ. सॉफ़्टवेयर की गुणवत्ता "आवश्यकताओं के अनुरूप एक सॉफ़्टवेयर उत्पाद की क्षमता" है। जबकि दूसरों के लिए यह ग्राहक-या मूल्य-निर्माण या यहां तक कि दोष स्तर का पर्याय भी हो सकता है। ए. एस. क्यू. ए. एस. क्यू. निम्नलिखित परिभाषा का उपयोग करता हैः सॉफ्टवेयर की गुणवत्ता सॉफ्टवेयर उत्पादों की वांछनीय विशेषताओं का वर्णन करती है। दो मुख्य दृष्टिकोण मौजूद हैंः दोष प्रबंधन और गुणवत्ता विशेषताएँ। एन. आई. एस. टी. सॉफ्टवेयर आश्वासन (एस. ए.) संपत्ति और इसे प्राप्त करने की प्रक्रिया दोनों को शामिल करता हैः [न्यायसंगत] विश्वास है कि सॉफ्टवेयर कमजोरियों से मुक्त है, या तो जानबूझकर सॉफ्टवेयर में डिज़ाइन किया गया है या अपने जीवन चक्र के दौरान किसी भी समय गलती से डाला गया है और यह कि सॉफ्टवेयर इच्छित तरीके से कार्य करता है गतिविधियों का नियोजित और व्यवस्थित सेट जो यह सुनिश्चित करता है कि सॉफ्टवेयर जीवन चक्र प्रक्रियाएं और उत्पाद आवश्यकताओं, मानकों और प्रक्रियाओं के अनुरूप हैं। जबकि सॉफ्टवेयर गुणवत्ता नियंत्रण (एस. सी. क्यू.) का अर्थ है "विकास या संशोधन के तहत सॉफ्टवेयर के लिए गुणवत्ता आवश्यकताओं की दिशा में कार्य उत्पादों की संतुष्टि सुनिश्चित करने के लिए तरीकों, उपकरणों, तकनीकों को लागू करने का ध्यान रखना"। अन्य सामान्य और ऐतिहासिक गुणवत्ता इतिहास की पहली परिभाषा 20वीं शताब्दी की शुरुआत में शेवहार्ट से याद की जाती हैः "गुणवत्ता के दो सामान्य पहलू हैंः उनमें से एक का संबंध किसी वस्तु की गुणवत्ता को मनुष्य के अस्तित्व से स्वतंत्र एक वस्तुनिष्ठ वास्तविकता के रूप में विचार करने से है। दूसरे का संबंध वस्तुनिष्ठ वास्तविकता के परिणामस्वरूप हम जो सोचते हैं, महसूस करते हैं या महसूस करते हैं, उससे है। दूसरे शब्दों में, गुणवत्ता का एक व्यक्तिपरक पक्ष है। किचनहैम और पफलीगर, डेविड गार्विन की शिक्षाओं को आगे बताते हुए, गुणवत्ता पर पाँच अलग-अलग दृष्टिकोणों की पहचान करते हैंः दिव्य परिप्रेक्ष्य गुणवत्ता के आध्यात्मिक पहलू से संबंधित है। गुणवत्ता के इस दृष्टिकोण में, यह "कुछ ऐसा है जिसके लिए हम एक आदर्श के रूप में प्रयास करते हैं, लेकिन कभी भी पूरी तरह से लागू नहीं कर सकते हैं।" इसे शायद ही परिभाषित किया जा सकता है, लेकिन यह वैसा ही है जैसा एक संघीय न्यायाधीश ने एक बार अश्लीलता के बारे में टिप्पणी की थीः "जब मैं इसे देखता हूं तो मुझे पता चलता है।" उपयोगकर्ता का दृष्टिकोण उपयोग के दिए गए संदर्भ के लिए उत्पाद की उपयुक्तता से संबंधित है। जबकि दिव्य दृश्य अलौकिक है, उपयोगकर्ता दृश्य अधिक ठोस है, जो उत्पाद विशेषताओं पर आधारित है जो उपयोगकर्ता की आवश्यकताओं को पूरा करते हैं। विनिर्माण परिप्रेक्ष्य आवश्यकताओं के अनुरूप गुणवत्ता का प्रतिनिधित्व करता है। गुणवत्ता के इस पहलू पर आईएसओ 9001 जैसे मानकों द्वारा जोर दिया जाता है, जो गुणवत्ता को "उस डिग्री के रूप में परिभाषित करता है जिस तक अंतर्निहित विशेषताओं का एक समूह आवश्यकताओं को पूरा करता है" (आईएसओ/आईईसी 9001)। उत्पाद के परिप्रेक्ष्य का तात्पर्य है कि उत्पाद की अंतर्निहित विशेषताओं को मापकर गुणवत्ता की सराहना की जा सकती है। गुणवत्ता का अंतिम परिप्रेक्ष्य मूल्य-आधारित है। यह परिप्रेक्ष्य यह मानता है कि गुणवत्ता के विभिन्न दृष्टिकोणों का विभिन्न हितधारकों के लिए अलग-अलग महत्व या मूल्य हो सकता है। टॉम डेमार्को ने प्रस्ताव दिया है कि "एक उत्पाद की गुणवत्ता इस बात का एक कार्य है कि यह दुनिया को बेहतर के लिए कितना बदल देता है।" इसकी व्याख्या इस अर्थ के रूप में की जा सकती है कि सॉफ्टवेयर की गुणवत्ता निर्धारित करने में संरचनात्मक गुणवत्ता की तुलना में कार्यात्मक गुणवत्ता और उपयोगकर्ता की संतुष्टि अधिक महत्वपूर्ण है। एक अन्य परिभाषा, जिसे गेराल्ड वेनबर्ग ने गुणवत्ता सॉफ्टवेयर प्रबंधनः सिस्टम थिंकिंग में गढ़ा था, वह है "गुणवत्ता किसी व्यक्ति के लिए मूल्य है"। यह परिभाषा इस बात पर जोर देती है कि गुणवत्ता स्वाभाविक रूप से व्यक्तिपरक है-अलग-अलग लोग एक ही सॉफ्टवेयर की गुणवत्ता का अलग-अलग अनुभव करेंगे। इस परिभाषा की एक ताकत वे प्रश्न हैं जिन पर यह सॉफ्टवेयर टीमों को विचार करने के लिए आमंत्रित करता है, जैसे कि "वे लोग कौन हैं जिन्हें हम अपने सॉफ्टवेयर को महत्व देना चाहते हैं?" और "उनके लिए क्या मूल्यवान होगा?" अन्य अर्थ और विवाद गुणवत्ता को परिभाषित करने में चुनौतियों में से एक यह है कि "हर कोई महसूस करता है कि वे इसे समझते हैं" और सॉफ्टवेयर गुणवत्ता की अन्य परिभाषाएं व्यवसाय में उपयोग की जाने वाली गुणवत्ता की अवधारणा के विभिन्न विवरणों के विस्तार पर आधारित हो सकती हैं। सॉफ्टवेयर की गुणवत्ता भी अक्सर गुणवत्ता आश्वासन या समस्या समाधान प्रबंधन या गुणवत्ता नियंत्रण या देवऑप्स के साथ मिश्रित हो जाती है। यह पहले उल्लिखित क्षेत्रों के साथ ओवर-लैप करता है (पीएमआई परिभाषाएँ भी देखें), लेकिन विशिष्ट है क्योंकि यह न केवल परीक्षण पर बल्कि प्रक्रियाओं, प्रबंधन, सुधार, मूल्यांकन आदि पर भी ध्यान केंद्रित करता है। यद्यपि इस खंड में प्रस्तुत अवधारणाएँ संरचनात्मक और कार्यात्मक सॉफ्टवेयर गुणवत्ता दोनों पर लागू होती हैं, लेकिन बाद वाले का मापन अनिवार्य रूप से परीक्षण के माध्यम से किया जाता है [मुख्य लेखः सॉफ्टवेयर परीक्षण देखें]। हालांकि, परीक्षण पर्याप्त नहीं हैः एक अध्ययन के अनुसार, व्यक्तिगत प्रोग्रामर अपने स्वयं के सॉफ्टवेयर में बग खोजने में 50 प्रतिशत से भी कम कुशल होते हैं। और परीक्षण के अधिकांश रूप केवल 35 प्रतिशत कुशल हैं। इससे [सॉफ्टवेयर] की गुणवत्ता निर्धारित करना मुश्किल हो जाता है। सॉफ्टवेयर की गुणवत्ता माप यह निर्धारित करने के बारे में है कि किसी प्रणाली या सॉफ्टवेयर में किस हद तक वांछनीय विशेषताएं हैं। यह गुणात्मक या मात्रात्मक साधनों या दोनों के मिश्रण के माध्यम से किया जा सकता है। दोनों ही मामलों में, प्रत्येक वांछनीय विशेषता के लिए, मापने योग्य विशेषताओं का एक समूह होता है जिसका अस्तित्व सॉफ्टवेयर या प्रणाली के एक टुकड़े में इस विशेषता के साथ सहसंबद्ध और संबद्ध होता है। उदाहरण के लिए, सुवाह्यता से जुड़ी एक विशेषता एक कार्यक्रम में लक्ष्य-निर्भर कथनों की संख्या है। अधिक सटीक रूप से, गुणवत्ता कार्य परिनियोजन दृष्टिकोण का उपयोग करते हुए, ये मापने योग्य विशेषताएँ "कैसे" हैं जिन्हें उपरोक्त सॉफ्टवेयर गुणवत्ता परिभाषा में "क्या" को सक्षम करने के लिए लागू करने की आवश्यकता है। सॉफ्टवेयर गुणवत्ता प्रबंधन पर लागू विशेषताओं और मेट्रिक्स की संरचना, वर्गीकरण और शब्दावली को आईएसओ 9126-3 और बाद के आईएसओ/आईईसी 25000:2005 गुणवत्ता मॉडल से प्राप्त या निकाला गया है। मुख्य ध्यान आंतरिक संरचनात्मक गुणवत्ता पर है। उपश्रेणियों को विशिष्ट क्षेत्रों जैसे व्यावसायिक अनुप्रयोग वास्तुकला और तकनीकी विशेषताओं जैसे डेटा पहुंच और हेरफेर या लेनदेन की धारणा को संभालने के लिए बनाया गया है। सॉफ्टवेयर गुणवत्ता विशेषताओं और उनकी मापने योग्य विशेषताओं के बीच निर्भरता वृक्ष को दाईं ओर आरेख में दर्शाया गया है, जहां उपयोगकर्ता (दाएं) या व्यवसाय प्रणाली के मालिक के लिए महत्वपूर्ण 5 विशेषताओं में से प्रत्येक मापने योग्य विशेषताओं पर निर्भर करती है (बाएं): अनुप्रयोग वास्तुकला अभ्यास कोडिंग अभ्यास अनुप्रयोग जटिलता प्रलेखन पोर्टेबिलिटी तकनीकी और कार्यात्मक मात्रा प्रोग्रामिंग त्रुटियों और उत्पादन दोषों के बीच संबंध से पता चलता है कि मूल कोड त्रुटियां स्रोत कोड में कुल त्रुटियों का 92 प्रतिशत हैं। ये कई कोड-स्तर के मुद्दे अंततः उत्पादन में केवल 10 प्रतिशत दोषों के लिए गिने जाते हैं। वास्तुकला स्तरों पर खराब सॉफ्टवेयर इंजीनियरिंग प्रथाएं कुल दोषों का केवल 8 प्रतिशत होती हैं, लेकिन समस्याओं को ठीक करने पर खर्च किए गए आधे से अधिक प्रयास का उपभोग करती हैं, और उत्पादन में गंभीर विश्वसनीयता, सुरक्षा और दक्षता के 90 प्रतिशत मुद्दों का कारण बनती हैं। कोड-आधारित विश्लेषण मौजूदा सॉफ़्टवेयर उपायों में से कई अनुप्रयोग के संरचनात्मक तत्वों को गिनते हैं जो ऐसे व्यक्तिगत निर्देश टोकन नियंत्रण संरचनाओं (जटिलता) और वस्तुओं के लिए स्रोत कोड को विश्लेषित करने के परिणामस्वरूप होते हैं। सॉफ्टवेयर गुणवत्ता मापन यह निर्धारित करने के बारे में है कि इन आयामों के साथ एक प्रणाली या सॉफ्टवेयर किस हद तक दर देता है। विश्लेषण एक समग्र दृष्टिकोण प्रदान करने के लिए एक गुणात्मक या मात्रात्मक दृष्टिकोण या दोनों के मिश्रण का उपयोग करके किया जा सकता है [उदाहरण के लिए भारित औसत (ओं) का उपयोग करना जो मापा जा रहा कारकों के बीच सापेक्ष महत्व को दर्शाता है]। एक रैखिक निरंतरता पर सॉफ्टवेयर गुणवत्ता के इस दृष्टिकोण को असतत महत्वपूर्ण प्रोग्रामिंग त्रुटियों की पहचान द्वारा पूरक किया जाना चाहिए। ये कमजोरियाँ एक परीक्षण मामले में विफल नहीं हो सकती हैं, लेकिन वे बुरी प्रथाओं का परिणाम हैं जो विशिष्ट परिस्थितियों में विनाशकारी आउटेज, प्रदर्शन क्षरण, सुरक्षा उल्लंघन, दूषित डेटा और असंख्य अन्य समस्याओं का कारण बन सकती हैं जो एक दिए गए सिस्टम को वास्तव में उपयोग के लिए अनुपयुक्त बनाती हैं, चाहे समग्र माप के आधार पर इसकी रेटिंग कुछ भी हो। भेद्यता का एक प्रसिद्ध उदाहरण सामान्य कमजोरी गणना है, जो स्रोत कोड में भेद्यताओं का एक भंडार है जो अनुप्रयोगों को सुरक्षा उल्लंघनों के संपर्क में लाता है। महत्वपूर्ण अनुप्रयोग विशेषताओं के मापन में अनुप्रयोग की वास्तुकला, कोडिंग और इन-लाइन प्रलेखन की संरचनात्मक विशेषताओं को मापना शामिल है, जैसा कि ऊपर दिए गए चित्र में दिखाया गया है। इस प्रकार, प्रत्येक विशेषता अनुप्रयोग में अमूर्तता के कई स्तरों पर विशेषताओं से प्रभावित होती है और इन सभी को विशेषता के माप की गणना करते हुए शामिल किया जाना चाहिए यदि यह व्यवसाय को प्रभावित करने वाले गुणवत्ता परिणामों का एक मूल्यवान भविष्यवक्ता होना है। उपरोक्त चित्र में प्रदर्शित विशेषता उपायों की गणना करने के लिए स्तरित दृष्टिकोण पहली बार टीआरडब्ल्यू (बोहम, 1978) में बोहम और उनके सहयोगियों द्वारा प्रस्तावित किया गया था और यह आईएसओ 9126 और 25000 श्रृंखला मानकों में लिया गया दृष्टिकोण है। इन विशेषताओं को अनुप्रयोग स्रोत कोड के स्थिर विश्लेषण के विश्लेषित परिणामों से मापा जा सकता है। यहां तक कि विश्वसनीयता और प्रदर्शन दक्षता जैसे अनुप्रयोगों की गतिशील विशेषताओं की जड़ें भी अनुप्रयोग की स्थिर संरचना में होती हैं। संरचनात्मक गुणवत्ता विश्लेषण और माप स्रोत कोड, वास्तुकला, सॉफ्टवेयर ढांचे, सिद्धांतों और मानकों के संबंध में डेटाबेस योजना के विश्लेषण के माध्यम से किया जाता है जो एक प्रणाली की वैचारिक और तार्किक वास्तुकला को एक साथ परिभाषित करते हैं। यह आम तौर पर विकास उपकरणों द्वारा किए जाने वाले बुनियादी, स्थानीय, घटक-स्तर के कोड विश्लेषण से अलग है जो ज्यादातर कार्यान्वयन विचारों से संबंधित हैं और डिबगिंग और परीक्षण गतिविधियों के दौरान महत्वपूर्ण हैं। विश्वसनीयता खराब विश्वसनीयता के मूल कारण अच्छी वास्तुकला और कोडिंग प्रथाओं के साथ गैर-अनुपालन के संयोजन में पाए जाते हैं। इस गैर-अनुपालन का पता किसी अनुप्रयोग की स्थिर गुणवत्ता विशेषताओं को मापकर लगाया जा सकता है। एक अनुप्रयोग की विश्वसनीयता में अंतर्निहित स्थिर विशेषताओं का आकलन व्यावसायिक जोखिम के स्तर और संभावित अनुप्रयोग विफलताओं और दोषों की संभावना का अनुमान प्रदान करता है जो अनुप्रयोग को संचालन में रखने पर अनुभव होगा। विश्वसनीयता का आकलन करने के लिए कम से कम निम्नलिखित सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं और तकनीकी विशेषताओं की जांच की आवश्यकता होती हैः अनुप्रयोग वास्तुकला अभ्यास कोडिंग अभ्यास एल्गोरिदम की जटिलता प्रोग्रामिंग प्रथाओं की जटिलता ऑब्जेक्ट-ओरिएंटेड और स्ट्रक्चर्ड प्रोग्रामिंग सर्वोत्तम प्रथाओं का अनुपालन (जब लागू हो) घटक या पैटर्न पुनः उपयोग अनुपात गंदी प्रोग्रामिंग त्रुटि और अपवाद हैंडलिंग (सभी परतों के लिए-जीयूआई, लॉजिक और डेटा) बहु-परत डिजाइन अनुपालन संसाधन सीमा प्रबंधन सॉफ्टवेयर उन पैटर्नों से बचता है जो अप्रत्याशित व्यवहार की ओर ले जाएंगे सॉफ्टवेयर डेटा अखंडता और स्थिरता लेनदेन जटिलता स्तर का प्रबंधन करता है अनुप्रयोग वास्तुकला और उपयोग किए गए तीसरे पक्ष के घटकों (जैसे बाहरी पुस्तकालय या ढांचे) के आधार पर, कस्टम जांच को सर्वोत्तम प्रथाओं की उपरोक्त सूची द्वारा तैयार की गई रेखाओं के साथ परिभाषित किया जाना चाहिए। विश्वसनीयता के साथ दक्षता, प्रदर्शन अक्षमता के कारण अक्सर अच्छे वास्तुकला और कोडिंग अभ्यास के उल्लंघन में पाए जाते हैं जिनका पता एक अनुप्रयोग की स्थिर गुणवत्ता विशेषताओं को मापकर लगाया जा सकता है। ये स्थिर विशेषताएँ संभावित परिचालन प्रदर्शन बाधाओं और भविष्य की मापनीयता समस्याओं की भविष्यवाणी करती हैं, विशेष रूप से जटिल एल्गोरिदम या बड़ी मात्रा में डेटा को संभालने के लिए उच्च निष्पादन गति की आवश्यकता वाले अनुप्रयोगों के लिए। प्रदर्शन दक्षता का आकलन करने के लिए कम से कम निम्नलिखित सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं और तकनीकी विशेषताओं की जांच करने की आवश्यकता होती हैः अनुप्रयोग वास्तुकला अभ्यास महंगे और/या दूरस्थ संसाधनों के साथ उपयुक्त बातचीत डेटा अभिगम प्रदर्शन और डेटा प्रबंधन स्मृति, नेटवर्क और डिस्क स्थान प्रबंधन कोडिंग प्रथाओं के साथ अनुपालन (सर्वश्रेष्ठ कोडिंग प्रथाएं) सुरक्षा सॉफ्टवेयर गुणवत्ता में सॉफ्टवेयर सुरक्षा शामिल है। कई सुरक्षा कमजोरियाँ खराब कोडिंग और वास्तुशिल्प प्रथाओं जैसे एस. क्यू. एल. इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग के परिणामस्वरूप होती हैं। ये सी. डब्ल्यू. ई. और कार्नेगी मेलन विश्वविद्यालय में एस. ई. आई./कंप्यूटर आपातकालीन केंद्र (सी. ई. आर. टी.) द्वारा रखी गई सूचियों में अच्छी तरह से प्रलेखित हैं। सुरक्षा का आकलन करने के लिए कम से कम निम्नलिखित सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं और तकनीकी विशेषताओं की जांच करने की आवश्यकता होती हैः कार्यान्वयन, सुरक्षा-जागरूक और सख्त विकास प्रक्रिया का प्रबंधन, जैसे। सुरक्षा विकास जीवनचक्र (माइक्रोसॉफ्ट) या आईबीएम का सुरक्षित इंजीनियरिंग ढांचा। सुरक्षित अनुप्रयोग वास्तुकला अभ्यास बहु-परत डिजाइन अनुपालन सुरक्षा सर्वोत्तम अभ्यास (इनपुट वैधीकरण, एसक्यूएल इंजेक्शन, क्रॉस-साइट स्क्रिप्टिंग, अभिगम नियंत्रण आदि) सुरक्षित और अच्छी प्रोग्रामिंग प्रथाएँ त्रुटि और अपवाद प्रबंधन रखरखाव में एकरूपता, समझ, परिवर्तनशीलता, परीक्षण क्षमता, पुनः प्रयोज्य और एक विकास दल से दूसरे में हस्तांतरण की अवधारणाएँ शामिल हैं। ये कोड स्तर पर महत्वपूर्ण मुद्दों का रूप नहीं लेते हैं। बल्कि, खराब रखरखाव आमतौर पर प्रलेखन, जटिलता से बचने की रणनीति और बुनियादी प्रोग्रामिंग प्रथाओं में सर्वोत्तम प्रथाओं के साथ हजारों मामूली उल्लंघनों का परिणाम है जो स्वच्छ और पढ़ने में आसान कोड बनाम असंगठित और पढ़ने में मुश्किल कोड के बीच अंतर करते हैं। रखरखाव का आकलन करने के लिए निम्नलिखित सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं और तकनीकी विशेषताओं की जांच करने की आवश्यकता होती हैः एप्लीकेशन आर्किटेक्चर प्रैक्टिस आर्किटेक्चर, कोड कोड पठनीयता कोड में एम्बेडेड प्रोग्राम और कोड प्रलेखन लेनदेन की जटिलता के स्तर को सूंघता है एल्गोरिदम की जटिलता प्रोग्रामिंग प्रथाओं की जटिलता ऑब्जेक्ट-ओरिएंटेड और स्ट्रक्चर्ड प्रोग्रामिंग के साथ अनुपालन सर्वोत्तम प्रथाएं (जब लागू हो) घटक या पैटर्न पुनः उपयोग अनुपात गतिशील कोडिंग युग्मन अनुपात का नियंत्रित स्तर डर्टी प्रोग्रामिंग डॉक्यूमेंटेशन हार्डवेयर, ओएस, मिडलवेयर, सॉफ्टवेयर घटक और डेटाबेस स्वतंत्रता बहु-परत डिजाइन अनुपालन पोर्टेबिलिटी प्रोग्रामिंग अभ्यास (कोड स्तर) कम डुप्लिकेट कोड और कार्य स्रोत कोड फ़ाइल संगठन स्वच्छता रखरखाव वार्ड कनिंघम की तकनीकी ऋण की अवधारणा से निकटता से संबंधित है, जो कि एक महत्वपूर्ण समाधान है। रखरखाव की क्षमता कम होने के कारणों को लापरवाह बनाम विवेकपूर्ण और जानबूझकर बनाम अनजाने के रूप में वर्गीकृत किया जा सकता है, और अक्सर विकासकर्ताओं की अक्षमता, समय और लक्ष्यों की कमी, उनकी लापरवाही और निर्माण लागत में विसंगतियों और प्रलेखन से लाभ और विशेष रूप से, रखरखाव योग्य स्रोत कोड में उनकी उत्पत्ति होती है। सॉफ़्टवेयर के आकार को मापने के लिए आवश्यक है कि पूरे स्रोत कोड को सही ढंग से एकत्र किया जाए, जिसमें डेटाबेस संरचना स्क्रिप्ट, डेटा हेरफेर स्रोत कोड, घटक हेडर, कॉन्फ़िगरेशन फ़ाइल आदि शामिल हैं। मापने के लिए अनिवार्य रूप से दो प्रकार के सॉफ्टवेयर आकार हैं, तकनीकी आकार (पदचिह्न) और कार्यात्मक आकारः कई सॉफ्टवेयर तकनीकी आकार विधियाँ हैं जिनका व्यापक रूप से वर्णन किया गया है। सबसे आम तकनीकी आकार विधि प्रति प्रौद्योगिकी कोड की पंक्तियों (#LOC) की संख्या, फ़ाइलों की संख्या, कार्यों, वर्गों, तालिकाओं आदि है, जिनसे बैकफायरिंग फ़ंक्शन बिंदुओं की गणना की जा सकती है; कार्यात्मक आकार को मापने के लिए सबसे आम फ़ंक्शन बिंदु विश्लेषण है। कार्य बिंदु विश्लेषण उपयोगकर्ता के दृष्टिकोण से वितरित करने योग्य सॉफ्टवेयर के आकार को मापता है। फंक्शन प्वाइंट साइजिंग उपयोगकर्ता की आवश्यकताओं के आधार पर किया जाता है और डेवलपर/प्राक्कलनकर्ता और मूल्य (वितरित की जाने वाली कार्यक्षमता) दोनों के लिए आकार का सटीक प्रतिनिधित्व प्रदान करता है और ग्राहक को दी जा रही व्यावसायिक कार्यक्षमता को दर्शाता है। विधि में उपयोगकर्ता द्वारा पहचाने जाने योग्य इनपुट, आउटपुट और डेटा स्टोर की पहचान और भार शामिल है। आकार मूल्य तब सॉफ्टवेयर वितरण और प्रदर्शन (प्रति कार्य बिंदु विकास लागत; प्रति कार्य बिंदु वितरित दोष; प्रति कर्मचारी महीने कार्य बिंदु) की मात्रा निर्धारित करने और मूल्यांकन करने के लिए कई उपायों के संयोजन के साथ उपयोग के लिए उपलब्ध है। फंक्शन प्वाइंट एनालिसिस साइजिंग स्टैंडर्ड इंटरनेशनल फंक्शन प्वाइंट यूज़र्स ग्रुप (आई. एफ. पी. यू. जी.) द्वारा समर्थित है। इसे सॉफ्टवेयर विकास जीवन-चक्र की शुरुआत में लागू किया जा सकता है और यह कुछ हद तक गलत बैकफायरिंग विधि जैसे कोड की पंक्तियों पर निर्भर नहीं है। विधि प्रौद्योगिकी अज्ञेयवादी है और इसका उपयोग संगठनों और उद्योगों में तुलनात्मक विश्लेषण के लिए किया जा सकता है। फंक्शन प्वाइंट एनालिसिस की शुरुआत के बाद से, कई भिन्नताएं विकसित हुई हैं और फंक्शनल साइजिंग तकनीकों के परिवार का विस्तार हुआ है जिसमें कॉस्मिक, एनईएसएमए, यूज़ केस पॉइंट्स, एफपी लाइट, अर्ली और क्विक एफपी और हाल ही में स्टोरी पॉइंट्स जैसे साइजिंग उपाय शामिल हैं। हालांकि, फंक्शन पॉइंट्स का सांख्यिकीय सटीकता का इतिहास रहा है, और इसका उपयोग कई अनुप्रयोग विकास प्रबंधन (ए. डी. एम.) या आउटसोर्सिंग व्यस्तताओं में कार्य माप की एक सामान्य इकाई के रूप में किया गया है, जो "मुद्रा" के रूप में कार्य करता है जिसके द्वारा सेवाओं को वितरित किया जाता है और प्रदर्शन को मापा जाता है। फंक्शन प्वाइंट कार्यप्रणाली की एक सामान्य सीमा यह है कि यह एक हस्तचालित प्रक्रिया है और इसलिए यह अनुप्रयोग विकास या आउटसोर्सिंग जुड़ाव जैसे बड़े पैमाने की पहलों में श्रम-गहन और महंगी हो सकती है। कार्यप्रणाली को लागू करने के इस नकारात्मक पहलू ने उद्योग के आई. टी. नेताओं को आई. टी. सॉफ्टवेयर गुणवत्ता के लिए कंसोर्टियम बनाने के लिए प्रेरित किया, जो सॉफ्टवेयर के आकार को स्वचालित रूप से मापने के लिए एक कम्प्यूटेबल मेट्रिक्स मानक शुरू करने पर केंद्रित था, जबकि आई. एफ. पी. यू. जी. एक मैनुअल दृष्टिकोण को बढ़ावा देता रहता है क्योंकि इसकी अधिकांश गतिविधि एफ. पी. काउंटर प्रमाणन पर निर्भर करती है। सी. आई. एस. क्यू. आकार को लागत अनुमान, प्रगति ट्रैकिंग या अन्य संबंधित सॉफ्टवेयर परियोजना प्रबंधन गतिविधियों का समर्थन करने के लिए सॉफ्टवेयर के आकार का अनुमान लगाने के रूप में परिभाषित करता है। दो मानकों का उपयोग किया जाता हैः सॉफ्टवेयर के कार्यात्मक आकार को मापने के लिए स्वचालित कार्य बिंदु और एक माप में कार्यात्मक और गैर-कार्यात्मक कोड दोनों के आकार को मापने के लिए स्वचालित वृद्धि बिंदु। महत्वपूर्ण प्रोग्रामिंग त्रुटियों की पहचान करना महत्वपूर्ण प्रोग्रामिंग त्रुटियां विशिष्ट वास्तुकला और/या खराब प्रथाओं को कोडिंग करना है जिसके परिणामस्वरूप उच्चतम, तत्काल या दीर्घकालिक, व्यावसायिक व्यवधान जोखिम होता है। ये अक्सर प्रौद्योगिकी से संबंधित होते हैं और संदर्भ, व्यावसायिक उद्देश्यों और जोखिमों पर बहुत अधिक निर्भर करते हैं। कुछ लोग परंपराओं के नामकरण के लिए सम्मान पर विचार कर सकते हैं जबकि अन्य-उदाहरण के लिए ज्ञान हस्तांतरण के लिए आधार तैयार करने वाले-इसे बिल्कुल महत्वपूर्ण मानेंगे। महत्वपूर्ण प्रोग्रामिंग त्रुटियों को सी. आई. एस. क्यू. विशेषताओं के अनुसार भी वर्गीकृत किया जा सकता है। नीचे दिया गया बुनियादी उदाहरण हैः विश्वसनीयता सॉफ्टवेयर पैटर्न से बचें जो अप्रत्याशित व्यवहार (अनइनिशियलाइज्ड वेरिएबल, नल पॉइंटर्स, आदि) की ओर ले जाएगा। डालने, अद्यतन करने, हटाने, तालिका बनाने या चुनने के तरीकों, प्रक्रियाओं और कार्यों में त्रुटि प्रबंधन शामिल होना चाहिए मल्टी-थ्रेड कार्यों को थ्रेड सुरक्षित बनाया जाना चाहिए, उदाहरण के लिए सर्वलेट्स या स्ट्रट्स एक्शन क्लासों में उदाहरण/गैर-अंतिम स्थिर क्षेत्र नहीं होने चाहिए दक्षता नेटवर्क ट्रैफिक को कम करने के लिए क्लाइंट अनुरोधों (आने और डेटा) का केंद्रीकरण सुनिश्चित करें एसक्यूएल प्रश्नों से बचें जो लूप में बड़ी तालिकाओं के खिलाफ सूचकांक का उपयोग नहीं करते हैं सुरक्षा सर्वलेट क्लासों में उन क्षेत्रों से बचें जो अंतिम स्थिर नहीं हैं त्रुटि प्रबंधन को शामिल किए बिना डेटा एक्सेस से बचें नियंत्रण रिटर्न कोड और त्रुटि हैंडलिंग तंत्र को लागू करें क्रॉस-साइट स्क्रिप्टिंग खामियों या एसक्यूएल इंजेक्शन खामियों से बचने के लिए इनपुट सत्यापन सुनिश्चित करें रखरखाव गहरी विरासत वाले पेड़ों और घोंसले से बचना चाहिए ताकि संकलन में सुधार हो सके। गुणवत्ता विशेषताओं को तोड़ने या अतिरिक्त परतों को परिभाषित करने से, जटिल, अमूर्त गुणवत्ता विशेषताएँ (जैसे विश्वसनीयता या रखरखाव) अधिक प्रबंधनीय और मापने योग्य हो जाती हैं। उन गुणवत्ता वाले मॉडलों को औद्योगिक संदर्भों में लागू किया गया है लेकिन उन्हें व्यापक रूप से अपनाया नहीं गया है। ट्रिविया "एक विज्ञान अपने माप उपकरण के रूप में परिपक्व है"। "जब मैं इसे देखता हूँ तो मुझे पता चलता है।" "आप उस चीज़ को नियंत्रित नहीं कर सकते जिसे आप माप नहीं सकते।" (टॉम डेमार्को) "आप किसी उत्पाद की गुणवत्ता का निरीक्षण नहीं कर सकते।" (डब्ल्यू. एडवर्ड्स डेमिंग) "खराब गुणवत्ता की कड़वाहट लंबे समय तक बनी रहती है जब कार्यक्रम को पूरा करने की मिठास को भुला दिया जाता है।" (बेनामी) "यदि आप एक विशिष्टता के साथ शुरुआत नहीं करते हैं, तो आपके द्वारा लिखे गए कोड का प्रत्येक टुकड़ा एक पैच है।" (लेस्ली लैम्पोर्ट) सॉफ्टवेयर बग एक्सेसिबिलिटी अवेलेबिलिटी भी देखें सर्वश्रेष्ठ कोडिंग अभ्यास सामंजस्य और युग्मन चक्रीय जटिलता कोडिंग सम्मेलन कंप्यूटर बग निर्भरता जीक्यूएम आईएसओ/आईईसी 9126 सॉफ्टवेयर प्रक्रिया सुधार और क्षमता निर्धारण-आईएसओ/आईईसी 15504 प्रोग्रामिंग शैली गुणवत्ताः गुणवत्ता नियंत्रण, कुल गुणवत्ता प्रबंधन। आवश्यकता प्रबंधन दायरा (परियोजना प्रबंधन) सुरक्षा सुरक्षा इंजीनियरिंग सॉफ्टवेयर गुणवत्ता आश्वासन सॉफ्टवेयर वास्तुकला सॉफ्टवेयर गुणवत्ता नियंत्रण सॉफ्टवेयर मेट्रिक्स सॉफ्टवेयर पुनः प्रयोज्य सॉफ्टवेयर मानक सॉफ्टवेयर परीक्षण परीक्षण स्थिरता कार्यक्रम विश्लेषण आगे पढ़ने के लिए एंड्रॉइड ओएस गुणवत्ता दिशानिर्देश जिसमें यूआई, सुरक्षा आदि के लिए चेकलिस्ट शामिल हैं। जुलाई 2021 सूचना प्रौद्योगिकी और संचार में समुद्री प्रबंधकों का संघ (ए. एम. एम. आई. टी. ई. सी.)। समुद्री सॉफ्टवेयर गुणवत्ता दिशानिर्देश। सितंबर 2017 कैपर्स जोन्स और ओलिवियर बोन्सिग्नोर, "सॉफ्टवेयर गुणवत्ता का अर्थशास्त्र", एडिसन-वेस्ली प्रोफेशनल, पहला संस्करण, 31 दिसंबर, 2011, कैट लैब-सीएनईएस कोड विश्लेषण उपकरण प्रयोगशाला (गिटहब पर) गिरीश सूर्यनारायण, सॉफ्टवेयर प्रक्रिया बनाम डिजाइन गुणवत्ताः रस्साकशी? हो-वोन जंग, सेउंग-ग्वेन किम और चांग-सिन चुंग। सॉफ्टवेयर उत्पाद की गुणवत्ता को मापनाः आईएसओ/आईईसी 9126 का एक सर्वेक्षण। आई. ई. ई. ई. सॉफ्टवेयर, 21 (5): 10-13, सितंबर/अक्टूबर 2004. मानकीकरण के लिए अंतर्राष्ट्रीय संगठन। सॉफ्टवेयर इंजीनियरिंग-उत्पाद की गुणवत्ता-भाग 1: गुणवत्ता मॉडल। आईएसओ, जिनेवा, स्विट्जरलैंड, 2001। आईएसओ/आईईसी 9126-1:2001 (ई)। सॉफ्टवेयर उत्पाद गुणवत्ता को मापनाः आईएसओ 25000 श्रृंखला और सीएमएमआई (एसईआई साइट) एमएसक्यूएफ-एक माप आधारित सॉफ्टवेयर गुणवत्ता ढांचा कॉर्नेल विश्वविद्यालय पुस्तकालय उमर अलशाथ्री, हेल्ज जानिक, "सॉफ्टवेयर गुणवत्ता आश्वासन को अनुकूलित करना", कॉम्प्सैक, पीपी। 87-92,2010 आई. ई. ई. ई. 34वीं वार्षिक कंप्यूटर सॉफ्टवेयर और अनुप्रयोग सम्मेलन कार्यशालाएं, 2010। रॉबर्ट एल. ग्लास। गुणवत्ता सॉफ्टवेयर का निर्माण। प्रेन्टिस हॉल, अपर सैडल रिवर, एन. जे., 1992। रोलैंड पेट्रास्च, "सॉफ्टवेयर गुणवत्ता की परिभाषाः एक व्यावहारिक दृष्टिकोण", आईएसएसआरई, 1999 सॉफ्टवेयर गुणवत्ता पेशेवर, अमेरिकन सोसाइटी फॉर क्वालिटी (एएसक्यू) सॉफ्टवेयर गुणवत्ता जर्नल स्प्रिंगर नेचर स्टीफन एच. कान. सॉफ्टवेयर गुणवत्ता इंजीनियरिंग में मेट्रिक्स और मॉडल। एडिसन-वेस्ली, बोस्टन, एमए, दूसरा संस्करण, 2002। स्टीफन वैगनर। सॉफ्टवेयर उत्पाद गुणवत्ता नियंत्रण। स्प्रिंगर, 2013। संदर्भ ग्रंथ सूची बाहरी लिंक जब कोड राजा हैः मोटर वाहन सॉफ्टवेयर उत्कृष्टता में महारत हासिल करना (मैकिन्से, 2021) अंतर्निहित सिस्टम सॉफ्टवेयर गुणवत्ताः यह अक्सर इतना भयानक क्यों होता है? हम इसके बारे में क्या कर सकते हैं? (फिलिप कूपमैन द्वारा) सी. आई. एस. क्यू. टी. एम. द्वारा कोड गुणवत्ता मानक सी. आई. एस. क्यू. ब्लॉगः सॉफ्टवेयर गुणवत्ता आश्वासन के लिए गाइड (ई. एस. ए.) छोटी सॉफ्टवेयर परियोजनाओं पर ई. एस. ए. सॉफ्टवेयर इंजीनियरिंग मानकों को लागू करने के लिए गाइड (ई. एस. ए.) ई. एस. ए. सॉफ्टवेयर उत्पाद आश्वासन सेवाओं का एक अवलोकन (नासा/ई. एस. ए.) वोक्सवैगन सॉफ्टवेयर देव केंद्र लिस्बन में गुणवत्ता के लिए हमारा दृष्टिकोण गूगल पर उत्पाद की गुणवत्ता सुनिश्चित करने के लिए गूगल स्टाइल गाइड (2011) नासा सॉफ्टवेयर आश्वासन एन. आई. एस. टी. सॉफ्टवेयर गुणवत्ता समूह ओ. एम. जी./सी. आई. एस. क्यू. स्वचालित कार्य बिंदु (आई. एस. ओ./आई. ई. सी. 19515) ओ. एम. जी. स्वचालित तकनीकी ऋण मानक स्वचालित गुणवत्ता आश्वासन (हैरी स्नीड द्वारा आई. आर. ई. बी. में व्यक्त) संरचित परीक्षणः चक्रवाती जटिलता का उपयोग करने वाली एक परीक्षण पद्धति।