सॉफ्टवेयर सत्यापन और मान्यता

From alpha
Jump to navigation Jump to search
IEEE software life cycle

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

परिभाषाएँ

सत्यापन और सत्यापन एक ही चीज़ नहीं हैं, हालाँकि वे अक्सर भ्रमित होते हैं। बैरी बोहम ने इस अंतर को संक्षेप में व्यक्त किया[1]

  • सत्यापन: क्या हम उत्पाद का निर्माण सही ढंग से कर रहे हैं?
  • मान्यता: क्या हम सही उत्पाद बना रहे हैं?

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

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

सॉफ़्टवेयर उत्पाद जारी किया गया है;[clarification needed] हालाँकि, हमेशा ऐसा ही हो यह जरूरी नहीं है।[lower-alpha 1]

सॉफ्टवेयर सत्यापन

इसका तात्पर्य यह सत्यापित करना होगा कि सॉफ़्टवेयर चलाने से विनिर्देश पूरे होते हैं या नहीं, लेकिन यह संभव नहीं है (उदाहरण के लिए, कोई कैसे जान सकता है कि सॉफ़्टवेयर चलाने से आर्किटेक्चर/डिज़ाइन/आदि सही ढंग से कार्यान्वित किया गया है या नहीं?)। केवल इससे जुड़ी कलाकृतियों की समीक्षा करके ही कोई यह निष्कर्ष निकाल सकता है कि विनिर्देश पूरे हुए हैं या नहीं।

विरूपण साक्ष्य या विशिष्टता सत्यापन

प्रत्येक सॉफ़्टवेयर विकास प्रक्रिया चरण का आउटपुट भी सत्यापन के अधीन हो सकता है जब उसके इनपुट विनिर्देश के विरुद्ध जाँच की जाती है (नीचे सीएमएमआई द्वारा परिभाषा देखें)।

विरूपण साक्ष्य सत्यापन के उदाहरण:

  • आवश्यकता विनिर्देश के विरुद्ध डिज़ाइन विनिर्देश का: क्या वास्तुशिल्प डिज़ाइन, विस्तृत डिज़ाइन और डेटाबेस तार्किक मॉडल विनिर्देश कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं विनिर्देशों को सही ढंग से लागू करते हैं?
  • डिज़ाइन विनिर्देश के विरुद्ध निर्माण कलाकृतियों में से: क्या स्रोत कोड, उपयोगकर्ता इंटरफ़ेस और डेटाबेस भौतिक मॉडल डिज़ाइन विनिर्देश को सही ढंग से लागू करते हैं?

सॉफ़्टवेयर सत्यापन

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

हालाँकि, यह पता लगाने के लिए आंतरिक स्थैतिक परीक्षण करना भी संभव है कि सॉफ़्टवेयर आवश्यकताओं के विनिर्देशों को पूरा करता है या नहीं, लेकिन यह स्थैतिक सत्यापन के दायरे में आता है क्योंकि सॉफ़्टवेयर नहीं चल रहा है।

विरूपण साक्ष्य या विशिष्टता सत्यापन

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

विरूपण साक्ष्य सत्यापन के उदाहरण:

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

सत्यापन बनाम सत्यापन

क्षमता परिपक्वता मॉडल (CMMI-SW v1.1) के अनुसार,[3]

  • सॉफ़्टवेयर सत्यापन: विकास प्रक्रिया के दौरान या उसके अंत में सॉफ़्टवेयर का मूल्यांकन करने की प्रक्रिया यह निर्धारित करने के लिए कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है। [आईईईई-एसटीडी-610]
  • सॉफ्टवेयर सत्यापन: यह निर्धारित करने के लिए सॉफ्टवेयर का मूल्यांकन करने की प्रक्रिया कि किसी दिए गए विकास चरण के उत्पाद उस चरण की शुरुआत में लगाई गई शर्तों को पूरा करते हैं या नहीं। [आईईईई-एसटीडी-610]

सॉफ़्टवेयर विकास प्रक्रिया के दौरान सत्यापन को उपयोगकर्ता आवश्यकताएँ विशिष्टता सत्यापन के एक रूप के रूप में देखा जा सकता है; और, विकास प्रक्रिया के अंत में यह आंतरिक और/या बाहरी सॉफ़्टवेयर सत्यापन के बराबर है। सीएमएमआई के दृष्टिकोण से सत्यापन, स्पष्ट रूप से विरूपण साक्ष्य प्रकार का है।

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

इस आलेख में सत्यापन की सख्त या सॉफ़्टवेयर सत्यापन#संकीर्ण गुंजाइश परिभाषा का उपयोग किया गया है।

परीक्षण के दृष्टिकोण से:

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

संबंधित अवधारणाएँ

सत्यापन और सत्यापन दोनों गुणवत्ता (व्यवसाय) और सॉफ्टवेयर गुणवत्ता आश्वासन की अवधारणाओं से संबंधित हैं। अपने आप में, सत्यापन और सत्यापन सॉफ़्टवेयर गुणवत्ता की गारंटी नहीं देते हैं; योजना, पता लगाने की क्षमता, कॉन्फ़िगरेशन प्रबंधन और सॉफ़्टवेयर इंजीनियरिंग के अन्य पहलुओं की आवश्यकता होती है।

मॉडलिंग और सिमुलेशन (एम एंड एस) समुदाय के भीतर, सत्यापन, सत्यापन और मान्यता की परिभाषाएँ समान हैं:

  • एम एंड एस सत्यापन यह निर्धारित करने की प्रक्रिया है कि एक कंप्यूटर मॉडल, सिमुलेशन, या मॉडल और सिमुलेशन कार्यान्वयन का फेडरेशन और उनके संबंधित डेटा डेवलपर के वैचारिक विवरण और विशिष्टताओं का सटीक रूप से प्रतिनिधित्व करते हैं।[4]* एम एंड एस सत्यापन उस डिग्री को निर्धारित करने की प्रक्रिया है जिससे मॉडल, सिमुलेशन, या मॉडल और सिमुलेशन का संघ, और उनके संबंधित डेटा इच्छित उपयोग के परिप्रेक्ष्य से वास्तविक दुनिया का सटीक प्रतिनिधित्व करते हैं।[4]
  • प्रत्यायन औपचारिक प्रमाणीकरण है कि एक मॉडल या सिमुलेशन किसी विशिष्ट उद्देश्य के लिए उपयोग करने के लिए स्वीकार्य है।[4]एम एंड एस सत्यापन की परिभाषा उस सटीकता पर केंद्रित है जिसके साथ एम एंड एस वास्तविक दुनिया के इच्छित उपयोग का प्रतिनिधित्व करता है। एम एंड एस सटीकता की डिग्री निर्धारित करना आवश्यक है क्योंकि सभी एम एंड एस वास्तविकता के अनुमान हैं, और यह निर्धारित करना आमतौर पर महत्वपूर्ण है कि क्या सन्निकटन की डिग्री इच्छित उपयोग के लिए स्वीकार्य है। यह सॉफ़्टवेयर सत्यापन के विपरीत है।

वी&वी विधियाँ

औपचारिक

मिशन-महत्वपूर्ण सॉफ़्टवेयर सिस्टम में, सिस्टम के सही संचालन को सुनिश्चित करने के लिए औपचारिक तरीकों का उपयोग किया जा सकता है। हालाँकि, ये औपचारिक तरीके महंगे साबित हो सकते हैं, जो कुल सॉफ़्टवेयर डिज़ाइन लागत का 80 प्रतिशत तक प्रतिनिधित्व करते हैं।

स्वतंत्र

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

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

आईएसवीवी परिणाम और निष्कर्ष सुधार और सुधार के लिए विकास टीमों को वापस भेज दिए जाते हैं।

इतिहास

ISVV सॉफ़्टवेयर में IV&V (स्वतंत्र सत्यापन और सत्यापन) के अनुप्रयोग से प्राप्त होता है। प्रारंभिक आईएसवीवी अनुप्रयोग (जैसा कि आज ज्ञात है) 1970 के दशक की शुरुआत में हुआ जब अमेरिकी सेना ने सेफगार्ड एंटी-बैलिस्टिक मिसाइल सिस्टम के लिए IV&V से संबंधित पहला महत्वपूर्ण कार्यक्रम प्रायोजित किया था।[7] दूसरा उदाहरण NASA का IV&V प्रोग्राम है, जिसे 1993 में स्थापित किया गया था।[8] 1970 के दशक के अंत तक IV&V तेजी से लोकप्रिय हो रहा था। सॉफ़्टवेयर की जटिलता, आकार और महत्व में निरंतर वृद्धि के कारण सॉफ़्टवेयर पर लागू IV&V की मांग बढ़ गई है।

इस बीच, IV&V (और सॉफ्टवेयर सिस्टम के लिए ISVV) समेकित हो गया और अब DoD, FAA, जैसे संगठनों द्वारा व्यापक रूप से उपयोग किया जाता है।[9] स्वतंत्र सत्यापन और सत्यापन सुविधा[8]और यूरोपीय अंतरिक्ष एजेंसी।[10] IV&V का उल्लेख DO-178B, ISO/IEC 12207 में किया गया है और IEEE 1012 में औपचारिक रूप दिया गया है।

ईएसए पर

शुरुआत में 2004-2005 में, यूरोपीय अंतरिक्ष एजेंसी के नेतृत्व में और डीएनवी जीएल, क्रिटिकल सॉफ्टवेयर, टर्मा ए/एस और एससीआईएसवाईएस द्वारा गठित एक यूरोपीय संघ ने आईएसवीवी को समर्पित एक गाइड का पहला संस्करण बनाया, जिसे स्वतंत्र सत्यापन और सत्यापन के लिए ईएसए गाइड कहा जाता है। अन्य संगठनों के समर्थन से.[11] यह मार्गदर्शिका आईएसवीवी से संबंधित सभी सॉफ्टवेयर इंजीनियरिंग चरणों पर लागू कार्यप्रणाली को कवर करती है।

2008 में यूरोपीय अंतरिक्ष एजेंसी ने दूसरा संस्करण जारी किया, जिसमें कई अलग-अलग यूरोपीय अंतरिक्ष आईएसवीवी हितधारकों से इनपुट प्राप्त हुए।[11]


कार्यप्रणाली

आईएसवीवी आमतौर पर पांच प्रमुख चरणों से बना होता है, इन चरणों को क्रमिक रूप से या सिलाई प्रक्रिया के परिणाम के रूप में निष्पादित किया जा सकता है।

योजना

  • आईएसवीवी गतिविधियों की योजना बनाना
  • सिस्टम क्रिटिकलिटी विश्लेषण: RAMS गतिविधियों के एक सेट के माध्यम से महत्वपूर्ण घटकों की पहचान (पैसे का मूल्य)
  • उपयुक्त तरीकों और उपकरणों का चयन

आवश्यकताएँ सत्यापन

  • इसके लिए सत्यापन: पूर्णता, शुद्धता, परीक्षणशीलता

डिज़ाइन सत्यापन

  • सॉफ्टवेयर आवश्यकताओं और इंटरफेस के लिए डिजाइन पर्याप्तता और अनुरूपता
  • आंतरिक और बाहरी स्थिरता
  • व्यवहार्यता और रखरखाव का सत्यापन

कोड सत्यापन

सत्यापन

  • अस्थिर घटकों/कार्यक्षमताओं की पहचान
  • सत्यापन त्रुटि प्रबंधन पर केंद्रित है: विकास टीम द्वारा किए गए सत्यापन के संबंध में पूरक (समवर्ती नहीं) सत्यापन
  • सॉफ्टवेयर और सिस्टम आवश्यकताओं का अनुपालन
  • ब्लैक बॉक्स परीक्षण और व्हाइट बॉक्स परीक्षण तकनीक
  • अनुभव आधारित तकनीकें

नियामक वातावरण

सॉफ़्टवेयर को अक्सर कानूनी रूप से विनियमित उद्योगों की अनुपालन आवश्यकताओं को पूरा करना चाहिए, जिसे अक्सर सरकारी एजेंसियों द्वारा निर्देशित किया जाता है[12][13] या औद्योगिक प्रशासनिक अधिकारी। उदाहरण के लिए, खाद्य एवं औषधि प्रशासन को सत्यापित करने के लिए सॉफ़्टवेयर संस्करण और पैच (कंप्यूटिंग) की आवश्यकता होती है।[14]


यह भी देखें

अग्रिम पठन

  • 1012-2012 IEEE Standard for System and Software Verification and Validation. 2012. doi:10.1109/IEEESTD.2012.6204026. ISBN 978-0-7381-7268-2.
  • Tran, E. (1999). "Verification/Validation/Certification". In Koopman, P. (ed.). Topics in Dependable Embedded Systems. Carnegie Mellon University. Retrieved 2007-05-18.
  • Menzies, T.; Y. Hu (2003). "Data mining for very busy people". Computer. 36 (1): 22–29. doi:10.1109/MC.2003.1244531.


बाहरी संबंध


संदर्भ

  1. ↑ Pham, H. (1999). सॉफ्टवेयर विश्वसनीयता. John Wiley & Sons, Inc. p. 567. ISBN 9813083840. Software Validation. The process of ensuring that the software is performing the right process. Software Verification. The process of ensuring that the software is performing the process right." Likewise and also there: "In short, Boehm (3) expressed the difference between the software verification and software validation as follows: Verification: Are we building the product right? Validation: Are we building the right product?.
  2. ↑ Snoderly, John; Faisandier, Alan. "System Verification". ISO/IEC/IEEE 15288. Archived from the original on 26 June 2023. Retrieved 18 May 2022.
  3. ↑ "सॉफ्टवेयर इंजीनियरिंग के लिए सीएमएमआई, संस्करण 1.1, चरणबद्ध प्रतिनिधित्व (सीएमएमआई-एसडब्ल्यू, वी1.1, चरणबद्ध)". resources.sei.cmu.edu. Retrieved 2021-03-20.
  4. ↑ 4.0 4.1 4.2 Department of Defense Documentation of Verification, Validation & Accreditation (VV&A) for Models and Simulations, Missile Defense Agency, 2008
  5. ↑ Rogers, R. (1981-10-26). "स्वतंत्र सॉफ़्टवेयर सत्यापन और सत्यापन के लिए योजना बनाना". 3rd Computers in Aerospace Conference. Computers in Aerospace Conference. San Diego, CA, U.S.: American Institute of Aeronautics and Astronautics. doi:10.2514/6.1981-2100.
  6. ↑ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (2008-05-12). "अंतरिक्ष अनुप्रयोगों के लिए एक स्वतंत्र सॉफ़्टवेयर सत्यापन और सत्यापन प्रक्रिया". SpaceOps 2008 Conference. Heidelberg, Germany: American Institute of Aeronautics and Astronautics. doi:10.2514/6.2008-3517. ISBN 978-1-62410-167-0.
  7. ↑ Lewis, Robert O. (1992). Independent verification and validation : a life cycle engineering process for quality software. New York: Wiley. ISBN 0-471-57011-7. OCLC 74908695.
  8. ↑ 8.0 8.1 Asbury, Michael (2015-03-09). "NASA के IV&V प्रोग्राम के बारे में". NASA. Retrieved 2021-03-20.
  9. ↑ Balci, O. (2010). "मॉडलिंग और सिमुलेशन अनुप्रयोगों के सत्यापन, सत्यापन, परीक्षण और प्रमाणन के सुनहरे नियम". S2CID 61476570. {{cite web}}: Missing or empty |url= (help)
  10. ↑ "फ़्लाइट सॉफ़्टवेयर सिस्टम अनुभाग (TEC-SWF)". www.esa.int. Retrieved 2021-03-20.
  11. ↑ 11.0 11.1 lavva.pt. "अंतरिक्ष के लिए नई आईएसवीवी गाइड पर काम चल रहा है". www.criticalsoftware.com. Retrieved 2021-03-20.
  12. ↑ "General Principles of Software validation; Final Guidance for Industry and FDA Staff" (PDF). Food and Drug Administration. 11 January 2002. Retrieved 12 July 2009.
  13. ↑ "Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application" (PDF). Food and Drug Administration. August 2003. Retrieved 12 July 2009.
  14. ↑ "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the Shelf (OTS) Software" (PDF). Food and Drug Administration. 14 January 2005. Retrieved 12 July 2009.



टिप्पणियाँ

  1. ↑ The term verification is often associated with the term validation and understood as a single concept of V&V. Validation is used to ensure that one is working the right problem, whereas verification is used to ensure that one has solved the problem right (Martin 1997). From an actual and etymological meaning, the term verification comes from the Latin verus, which means truth, and facere, which means to make/perform. Thus, verification means to prove that something is true or correct (a property, a characteristic, etc.). The term validation comes from the Latin valere, which means to become strong, and has the same etymological root as the word value. Thus, validation means to prove that something has the right features to produce the expected effects. (Adapted from "Verification and Validation in plain English" (Lake INCOSE 1999).[2]

[[pt:Qualidade de softwa

Retrieved from "https://alpha.indicwiki.in/index.php?title=सॉफ्टवेयर_सत्यापन_और_मान्यता&oldid=332887"