वी-मॉडल: Difference between revisions

Revision as of 10:41, 20 July 2023

प्रणाली इंजीनियरिंग प्रक्रिया का वी-मॉडल।^[1]

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

V का बायाँ भाग आवश्यकताओं के अपघटन एवं प्रणाली विशिष्टताओं के निर्माण का प्रतिनिधित्व करता है। V का दाहिना भाग भागों के एकीकरण एवं उनके सत्यापन को दर्शाता है।^[3]^[4]^[5]^[6]^[7] चूँकि, आवश्यकताओं को पूर्व उच्च स्तरीय आवश्यकताओं या उपयोगकर्ता की आवश्यकताओं के विरुद्ध मान्य करने की आवश्यकता है। इसके अतिरिक्त, प्रणाली मॉडल के सत्यापन के रूप में भी कुछ है। इसे आंशिक रूप से बायीं ओर भी किया जा सकता है। यह दावा करना कि सत्यापन केवल दाईं ओर होता है, उचित नहीं हो सकता है। सबसे सरल उपाय यह कहना है कि सत्यापन सदैव आवश्यकताओं (प्रौद्योगिकी शर्तों) के विरुद्ध होता है एवं सत्यापन सदैव वास्तविक समाज या उपयोगकर्ता की आवश्यकताओं के विरुद्ध होता है। एयरोस्पेस मानक RTCA DO-178B बताता है कि आवश्यकताओं को मान्य किया गया है - सत्य होने की पुष्टि की गई है - एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।

मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप उचित चीज़ बना रहे हैं? एवं सत्यापन के साथ कि क्या आप इसे उचित उचित से बना रहे हैं?

प्रकार

वी-मॉडल के तीन सामान्य प्रकार हैं।

वी-मॉडेल

वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः PRINCE2 के समान है, परन्तु सॉफ्टवेयर विकास के लिए अधिक सीधे प्रासंगिक है।^[8] वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि वी के बाईं ओर के उत्पाद वी के दाईं ओर को प्रस्तावित करने वाले उपयुक्त परीक्षण एवं एकीकरण संगठन द्वारा स्वीकार्य थे।^[9]^[10]^[11]

सामान्य परीक्षण

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

अमेरिकी सरकार मानक

अमेरिका में सरकारी मानक वी-मॉडल भी है जो लगभग 20 साल प्राचीन है। इसका दायरा संकीर्ण प्रणाली विकास जीवनचक्र मॉडल है, परन्तु अधिकांश यूके चिकित्सकों एवं परीक्षकों द्वारा वी-मॉडल द्वारा समझे जाने की अपेक्षा में कहीं अधिक विस्तृत एवं अधिक कठोर है।^[13]^[14]^[3]^[4]^[15]^[16]

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

कभी-कभी यह कहा जाता है कि मान्यता इस प्रश्न द्वारा व्यक्त की जा सकती है कि क्या आप उचित चीज़ का निर्माण कर रहे हैं? एवं सत्यापन द्वारा क्या आप इसे उचित ढंग से बना रहे हैं? व्यवहार में, इन शब्दों का उपयोग भिन्न-भिन्न होता है।

प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए गाइड, जिसे आईईईई द्वारा मानक के रूप में भी अपनाया गया है (इनकोस, प्रणाली इंजीनियरिंग रिसर्च काउंसिल एसईआरसी एवं आईईईई कंप्यूटर सोसाइटी द्वारा संयुक्त रूप से बनाए रखा गया है) उन्हें अपने चौथे संस्करण में निम्नानुसार परिभाषित करता है:^[17]

सत्यापन. यह आश्वासन कि कोई उत्पाद, सेवा या प्रणाली ग्राहक एवं अन्य पहचाने गए हितधारकों की जरूरतों को पूर्ण करती है। इसमें प्रायः बाहरी ग्राहकों के साथ स्वीकृति एवं उपयुक्तता सम्मिलित होती है। सत्यापन से अपेक्षा करें।
सत्यापन. कोई उत्पाद, सेवा या प्रणाली किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई शर्त का अनुपालन करता है या नहीं करता है। यह प्रायः आंतरिक प्रक्रिया होती है। सत्यापन से अपेक्षा करें।

उद्देश्य

वी-मॉडल परियोजनाओं की योजना एवं कार्यान्वयन के लिए मार्गदर्शन प्रदान करता है। परियोजना कार्यान्वयन द्वारा निम्नलिखित उद्देश्यों को प्राप्त करने का इरादा है:

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

वी-मॉडल विषय

प्रणाली इंजीनियरिंग एवं सत्यापन.^[18]

प्रणाली इंजीनियरिंग एवं सत्यापन

प्रणाली इंजीनियरिंग प्रक्रिया (एसईपी) जटिल प्रणालियों की लागत-प्रभावशीलता में सुधार के लिए मार्ग प्रदान करती है जैसा कि प्रणाली के मालिक द्वारा गर्भाधान से लेकर सेवानिवृत्ति तक, प्रणाली के पूरे जीवन में अनुभव किया जाता है।^[1]

इसमें लक्ष्यों की प्रारंभिक एवं व्यापक पहचान, संचालन की अवधारणा जो उपयोगकर्ता की जरूरतों एवं ऑपरेटिंग वातावरण, संपूर्ण एवं परीक्षण योग्य प्रणाली आवश्यकताओं, विस्तृत डिजाइन, कार्यान्वयन, कार्यान्वित प्रणाली की कठोर स्वीकृति परीक्षण का वर्णन करती है ताकि यह सुनिश्चित किया जा सके कि यह बताई गई आवश्यकताओं को पूर्ण करती है (प्रणाली सत्यापन) ), लक्ष्यों को संबोधित करने (प्रणाली सत्यापन), चालू संचालन एवं रखरखाव, समय के साथ प्रणाली अपग्रेड एवं अंततः सेवानिवृत्ति में इसकी प्रभावशीलता को मापना।^[1]^[3]^[4]^[7]

यह प्रक्रिया आवश्यकताओं-संचालित डिजाइन एवं परीक्षण पर जोर देती है। सभी डिज़ाइन तत्व एवं स्वीकृति परीक्षण या अधिक प्रणाली आवश्यकताओं के अनुरूप होने चाहिए एवं प्रत्येक आवश्यकता को कम से कम डिज़ाइन तत्व एवं स्वीकृति परीक्षण द्वारा संबोधित किया जाना चाहिए। ऐसी कठोरता यह सुनिश्चित करती है कि कुछ भी अनावश्यक रूप से नहीं किया जाए एवं जो कुछ आवश्यक है वह पूर्ण किया जाए।^[1]^[3]

दो धाराएँ

विशिष्टता स्ट्रीम

विशिष्टता स्ट्रीम में मुख्य रूप से सम्मिलित हैं:

उपयोगकर्ता आवश्यकता विनिर्देश
कार्यात्मक आवश्यकता विनिर्देश
डिजाइन विनिर्देश

परीक्षण स्ट्रीम

परीक्षण स्ट्रीम में आम तौर पर निम्न सम्मिलित होते हैं:

स्थापना योग्यता (आईक्यू)
परिचालन योग्यता (ओक्यू)
प्रदर्शन योग्यता (पीक्यू)

विकास स्ट्रीम में अनुकूलन, कॉन्फ़िगरेशन या कोडिंग (प्रणाली प्रकार एवं विकास के दायरे के आधार पर) सम्मिलित हो सकती है।

अनुप्रयोग

File:VPM3e Vee with detail.gif

ऑफ-कोर विकल्प (ऊपर एवं नीचे की ओर पुनरावृत्तियों एवं समय एवं परिपक्वता आयाम को दर्शाते हुए)। स्रोत - के. फ़ोर्सबर्ग एवं एच. मूज़ 2004^[3]^[7]

वी-मॉडल का उपयोग जर्मन संघीय प्रशासन के अंदर सॉफ्टवेयर विकास प्रक्रिया को विनियमित करने के लिए किया जाता है। आजकल^[when?] यह अभी भी जर्मन संघीय प्रशासन एवं रक्षा परियोजनाओं के साथ-साथ क्षेत्र के सॉफ्टवेयर डेवलपर्स के लिए मानक है।

वी-मॉडल की अवधारणा 1980 के दशक के अंत में जर्मनी एवं संयुक्त राज्य अमेरिका में साथ, परन्तु स्वतंत्र रूप से विकसित की गई थी:

जर्मन वी-मॉडल मूल रूप से म्यूनिख के पास ओटोब्रून में आईएबीजी द्वारा, संघीय रक्षा मंत्रालय के लिए कोबलेनज़ में रक्षा प्रौद्योगिकी एवं खरीद के संघीय कार्यालय के सहयोग से विकसित किया गया था। इसे 1992 की गर्मियों में नागरिक सार्वजनिक प्राधिकरण डोमेन के लिए संघीय आंतरिक मंत्रालय द्वारा अपने अधिकार में ले लिया गया था।^[19]
यूएस वी-मॉडल, जैसा कि 1991 में प्रणाली इंजीनियरिंग पर अंतर्राष्ट्रीय परिषद (एनसीओएसई; अब 1995 में आईएनसीओएसई) की कार्यवाही में प्रलेखित किया गया है।^[7]हार्डवेयर, सॉफ्टवेयर एवं मानव संपर्क से जुड़े उपग्रह प्रणालियों के लिए विकसित किया गया था।
वी-मॉडल पहली बार एफएए एडवांस्ड ऑटोमेशन प्रणाली (एएएस) कार्यक्रम के पूर्व-प्रस्ताव प्रयास के हिस्से के रूप में ह्यूजेस विमान में लगभग 1982 में दिखाई दिया। इसने अंततः ह्यूजेस एएएस डिज़ाइन प्रतियोगिता चरण (डीसीपी) प्रस्ताव के लिए परीक्षण रणनीति बनाई। इसे परीक्षण एवं ीकरण दृष्टिकोण को दिखाने के लिए बनाया गया था जो सॉफ़्टवेयर में गुप्त दोषों को सामने लाने की नई चुनौतियों से प्रेरित था। अव्यक्त दोष का पता लगाने के इस नए स्तर की आवश्यकता हवाई यातायात नियंत्रक की सोच एवं योजना प्रक्रियाओं को स्वचालित करना शुरू करने के लक्ष्य से प्रेरित थी, जैसा कि स्वचालित एनरूट हवाई यातायात नियंत्रण (एईआरए) कार्यक्रम द्वारा कल्पना की गई थी। वी के इतने शक्तिशाली होने का कारण सभी पाठ एवं विश्लेषण को बहुआयामी छवियों के साथ जोड़ने की ह्यूजेस संस्कृति से आता है। यह प्रकाशनों के अनुक्रमिक विषयगत संगठन (STOP) की नींव थी। ^[20] 1963 में ह्यूजेस द्वारा बनाया गया एवं 1985 में हावर्ड ह्यूजेस मेडिकल इंस्टीट्यूट द्वारा ह्यूजेस का विनिवेश होने तक इसका उपयोग किया गया।^[21]
अमेरिकी रक्षा विभाग प्रणाली अभियांत्रिकी प्रक्रिया इंटरैक्शन को वी-मॉडल संबंध में रखता है।^[22]

इसे अब वाणिज्यिक एवं साथ ही रक्षा कार्यक्रमों में व्यापक अनुप्रयोग मिल गया है। इसका प्राथमिक उपयोग परियोजना प्रबंधन में है^[3]^[4]एवं पूरे प्रोजेक्ट जीवनचक्र के समय।

यूएस वी-मॉडल की मूलभूत विशेषता यह है कि समय एवं परिपक्वता बाएं से दाएं की ओर चलती है एवं कोई भी समय में पीछे नहीं जा सकता है। जैसा कि चित्र में दिखाया गया है, सभी पुनरावृत्ति प्रणाली पदानुक्रम में उच्च या निम्न स्तर तक ऊर्ध्वाधर रेखा के साथ होती है।^[3]^[4]^[7] यह मॉडल का महत्वपूर्ण पहलू साबित हुआ है। मॉडल के दोहरे-वी अवधारणा के विस्तार को संदर्भ में माना जाता है।^[3]

चूँकि V-मॉडल सार्वजनिक रूप से उपलब्ध है इसलिए कई कंपनियाँ भी इसका उपयोग करती हैं। परियोजना प्रबंधन में यह PRINCE2 की अपेक्षा में विधि है एवं परियोजना प्रबंधन के तरीकों के साथ-साथ प्रणाली विकास जीवनचक्र के तरीकों का वर्णन करती है। वी-मॉडल, प्रक्रिया में कठोर होते हुए भी, अनुप्रयोग में बहुत लचीला हो सकता है, खासकर जब यह प्रणाली डेवलपमेंट जीवनचक्र के सामान्य मापदंडों के दायरे से बाहर के दायरे से संबंधित है।

लाभ

अन्य प्रणाली विकास मॉडल के सामने वी-मॉडल के ये फायदे हैं:

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

सीमाएँ

निम्नलिखित पहलुओं को वी-मॉडल द्वारा कवर नहीं किया गया है, उन्हें अतिरिक्त रूप से विनियमित किया जाना चाहिए, या वी-मॉडल को तदनुसार अनुकूलित किया जाना चाहिए:^[25]^[26]

सेवाओं के लिए अनुबंध रखना विनियमित नहीं है।
प्रणाली के संचालन, रखरखाव, मरम्मत एवं निपटान का संगठन एवं निष्पादन वी-मॉडल द्वारा कवर नहीं किया जाता है। चूँकि, इन कार्यों के लिए अवधारणा की योजना एवं तैयारी को वी-मॉडल में विनियमित किया जाता है।
वी-मॉडल पूरे संगठन के बजाय परियोजना के अंदर सॉफ्टवेयर विकास को संबोधित करता है।

यह भी देखें

इंजीनियरिंग सूचना प्रबंधन (ईआईएम)
अर्काडिया (इंजीनियरिंग) (सपोर्टिंग प्रणाली मॉडलिंग विधि के रूप में)
आईबीएम तर्कसंगत ीकृत प्रक्रिया ( सहायक सॉफ्टवेयर प्रक्रिया के रूप में)
सॉफ्टवेयर विकास का झरना मॉडल
प्रणाली आर्किटेक्चर
प्रणाली डिज़ाइन
प्रणाली अभियांत्रिकी
मॉडल-आधारित प्रणाली इंजीनियरिंग
सिद्धांत यू

संदर्भ

↑ ^1.0 ^1.1 ^1.2 ^1.3 Clarus Concept of Operations Archived 2009-07-05 at the Wayback Machine, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.
↑ "The Dangerous & Seductive V Model" Archived 2019-09-15 at the Wayback Machine, accessed January 9, 2013.
↑ ^3.0 ^3.1 ^3.2 ^3.3 ^3.4 ^3.5 ^3.6 ^3.7 Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.
↑ ^4.0 ^4.1 ^4.2 ^4.3 ^4.4 International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8
↑ Forsberg, K., Mooz, H. (1998). "तेज़, सस्ता, बेहतर के लिए सिस्टम इंजीनियरिंग" (PDF). Center of Systems Management. Archived from the original (PDF) on April 20, 2003. {{cite journal}}: Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link)
↑

[FHWA_05-1] 1.0 ^1.1 ^1.2 ^1.3 Clarus Concept of Operations Archived 2009-07-05 at the Wayback Machine, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.

[2] "The Dangerous & Seductive V Model" Archived 2019-09-15 at the Wayback Machine, accessed January 9, 2013.

[VPM-3] 3.0 ^3.1 ^3.2 ^3.3 ^3.4 ^3.5 ^3.6 ^3.7 Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.

[INCOSE-4] 4.0 ^4.1 ^4.2 ^4.3 ^4.4 International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8

[5] Forsberg, K., Mooz, H. (1998). "तेज़, सस्ता, बेहतर के लिए सिस्टम इंजीनियरिंग" (PDF). Center of Systems Management. Archived from the original (PDF) on April 20, 2003. {{cite journal}}: Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link)

[6] ↑

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

@@ Line 1: / Line 1: @@
 {{Short description|Graphic of a systems development lifecycle}}
-{{For|the version specific to software development|V-model (software development)}}
+{{For|
+सॉफ़्टवेयर विकास के लिए विशिष्ट संस्करण|वी-मॉडल (सॉफ्टवेयर विकास)}}
 [[Image:Systems Engineering Process II.svg|thumb|420px|प्रणाली इंजीनियरिंग प्रक्रिया का वी-मॉडल।<ref name="FHWA 05">[http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm ''Clarus Concept of Operations''] {{Webarchive|url=https://web.archive.org/web/20090705102900/http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm |date=2009-07-05 }}, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.</ref>]]
 {{Software development process}}
-'''वी-मॉडल''' [[सिस्टम विकास जीवनचक्र|प्रणाली विकास जीवनचक्र]] का  ग्राफिकल प्रतिनिधित्व है। इसका उपयोग कठोर विकास जीवनचक्र मॉडल एवं परियोजना प्रबंधन मॉडल तैयार करने के लिए किया जाता है। वी-मॉडल तीन व्यापक श्रेणियों, जर्मन ''वी-मॉडेल'',  सामान्य परीक्षण मॉडल एवं अमेरिकी सरकार मानक में आता है।<ref>[http://www.clarotesting.com/page11.htm#coherence "The Dangerous & Seductive V Model"] {{Webarchive|url=https://web.archive.org/web/20190915230955/http://www.clarotesting.com/page11.htm |date=2019-09-15}}, accessed January 9, 2013.</ref>वी-मॉडल कम्प्यूटरीकृत प्रणाली सत्यापन ढांचे, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणोंका सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।
+'''वी-मॉडल''' [[सिस्टम विकास जीवनचक्र|प्रणाली विकास जीवनचक्र]] का  ग्राफिकल प्रतिनिधित्व है। इसका उपयोग कठोर विकास जीवनचक्र मॉडल एवं परियोजना प्रबंधन मॉडल तैयार करने के लिए किया जाता है। वी-मॉडल तीन व्यापक श्रेणियों, जर्मन वी-मॉडेल, सामान्य परीक्षण मॉडल एवं अमेरिकी सरकार मानक में आता है।<ref>[http://www.clarotesting.com/page11.htm#coherence "The Dangerous & Seductive V Model"] {{Webarchive|url=https://web.archive.org/web/20190915230955/http://www.clarotesting.com/page11.htm |date=2019-09-15}}, accessed January 9, 2013.</ref>वी-मॉडल कम्प्यूटरीकृत प्रणाली सत्यापन ढांचे, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणोंका सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।
-V का बायाँ भाग आवश्यकताओं के अपघटन एवं प्रणाली विशिष्टताओं के निर्माण का प्रतिनिधित्व करता है। V का दाहिना भाग भागों के एकीकरण एवं उनके सत्यापन को दर्शाता है।<ref name="VPM" /><ref name="INCOSE" /><ref>{{cite journal|year=1998|title=तेज़, सस्ता, बेहतर के लिए सिस्टम इंजीनियरिंग|url=http://www.incose.org/sfbac/welcome/fcb-csm.pdf|publisher=Center of Systems Management|author=Forsberg, K., Mooz, H.|archive-url=https://web.archive.org/web/20030420130303/http://www.incose.org/sfbac/welcome/fcb-csm.pdf|archive-date=April 20, 2003}}</ref><ref>{{cite web|url=http://www.gmu.edu/departments/seor/insert/robot/robot2.html|title=एसई वीईई|publisher=SEOR, George Mason University|access-date=May 26, 2007|archive-url=https://web.archive.org/web/20071018220159/http://www.gmu.edu/departments/seor/insert/robot/robot2.html|archive-date=October 18, 2007|url-status=dead|df=mdy-all}}</ref><ref name="Original">Forsberg, K. and Mooz, H., [http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf "The Relationship of Systems Engineering to the Project Cycle"] {{Webarchive|url=https://web.archive.org/web/20090227123750/http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf |date=2009-02-27 }}, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991</ref> चूँकि, आवश्यकताओं को पूर्व उच्च स्तरीय आवश्यकताओं या उपयोगकर्ता की आवश्यकताओं के विरुद्ध मान्य करने की आवश्यकता है। इसके अतिरिक्त, प्रणाली मॉडल के सत्यापन के रूप में भी कुछ है। इसे आंशिक रूप से बायीं ओर भी किया जा सकता है। यह दावा करना कि सत्यापन केवल दाईं ओर होता है, उचित नहीं हो सकता है। सबसे सरल उपाय यह कहना है कि सत्यापन हमेशा आवश्यकताओं (प्रौद्योगिकी शर्तों) के विरुद्ध होता है एवं सत्यापन हमेशा वास्तविक समाज या उपयोगकर्ता की आवश्यकताओं के विरुद्ध होता है। एयरोस्पेस मानक RTCA [[DO-178B]] बताता है कि आवश्यकताओं को मान्य किया गया है - सत्य होने की पुष्टि की गई है - एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।
+V का बायाँ भाग आवश्यकताओं के अपघटन एवं प्रणाली विशिष्टताओं के निर्माण का प्रतिनिधित्व करता है। V का दाहिना भाग भागों के एकीकरण एवं उनके सत्यापन को दर्शाता है।<ref name="VPM" /><ref name="INCOSE" /><ref>{{cite journal|year=1998|title=तेज़, सस्ता, बेहतर के लिए सिस्टम इंजीनियरिंग|url=http://www.incose.org/sfbac/welcome/fcb-csm.pdf|publisher=Center of Systems Management|author=Forsberg, K., Mooz, H.|archive-url=https://web.archive.org/web/20030420130303/http://www.incose.org/sfbac/welcome/fcb-csm.pdf|archive-date=April 20, 2003}}</ref><ref>{{cite web|url=http://www.gmu.edu/departments/seor/insert/robot/robot2.html|title=एसई वीईई|publisher=SEOR, George Mason University|access-date=May 26, 2007|archive-url=https://web.archive.org/web/20071018220159/http://www.gmu.edu/departments/seor/insert/robot/robot2.html|archive-date=October 18, 2007|url-status=dead|df=mdy-all}}</ref><ref name="Original">Forsberg, K. and Mooz, H., [http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf "The Relationship of Systems Engineering to the Project Cycle"] {{Webarchive|url=https://web.archive.org/web/20090227123750/http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf |date=2009-02-27 }}, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991</ref> चूँकि, आवश्यकताओं को पूर्व उच्च स्तरीय आवश्यकताओं या उपयोगकर्ता की आवश्यकताओं के विरुद्ध मान्य करने की आवश्यकता है। इसके अतिरिक्त, प्रणाली मॉडल के सत्यापन के रूप में भी कुछ है। इसे आंशिक रूप से बायीं ओर भी किया जा सकता है। यह दावा करना कि सत्यापन केवल दाईं ओर होता है, उचित नहीं हो सकता है। सबसे सरल उपाय यह कहना है कि सत्यापन सदैव आवश्यकताओं (प्रौद्योगिकी शर्तों) के विरुद्ध होता है एवं सत्यापन सदैव वास्तविक समाज या उपयोगकर्ता की आवश्यकताओं के विरुद्ध होता है। एयरोस्पेस मानक RTCA [[DO-178B]] बताता है कि आवश्यकताओं को मान्य किया गया है - सत्य होने की पुष्टि की गई है - एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।
-मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप उचित चीज़ बना रहे हैं? एवं सत्यापन के साथ कि क्या आप इसे उचित ढंग से बना रहे हैं?
+मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप उचित चीज़ बना रहे हैं? एवं सत्यापन के साथ कि क्या आप इसे उचित उचित से बना रहे हैं?
 == प्रकार ==

Anonymous

Search