वी-मॉडल - Revision history

Abhishekkshukla at 07:00, 8 September 2023

2023-09-08T07:00:07Z

← Older revision		Revision as of 12:30, 8 September 2023
Line 1:		Line 1:
	{{Short description\|Graphic of a systems development lifecycle}}		{{Short description\|Graphic of a systems development lifecycle}}
	~~{{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>]]'''वी-मॉडल''' [[सिस्टम विकास जीवनचक्र]] का ग्राफिकल प्रतिनिधित्व है। इसका उपयोग कठोर विकास जीवनचक्र मॉडल एवं परियोजना प्रबंधन मॉडल प्रस्तुत करने के लिए किया जाता है। वी-मॉडल तीन व्यापक श्रेणियों, जर्मन वी-मॉडेल, सामान्य परीक्षण मॉडल एवं अमेरिकी सरकार मानक में आता है।<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>वी-मॉडल कम्प्यूटरीकृत सिस्टम सत्यापन फ्रेम, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणों का सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।
	~~सॉफ़्टवेयर विकास के लिए विशिष्ट संस्करण\|वी-मॉडल (सॉफ्टवेयर विकास)}}~~
	[[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>वी-मॉडल कम्प्यूटरीकृत सिस्टम सत्यापन फ्रेम, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणों का सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।

	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]] बताता है कि आवश्यकताओं को मान्य किया गया है, सत्य होने की पुष्टि की गई है एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।

Abhishekkshukla: /* बाहरी संबंध */

2023-09-08T06:59:53Z

बाहरी संबंध

← Older revision		Revision as of 12:29, 8 September 2023
Line 131:		Line 131:
	* {{cite web \|url=http://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html \|title=Das V-Modell XT \|website=cio.bund.de \|publisher=[[Federal Office for Information Security]] (BMI) \|language=de}}		* {{cite web \|url=http://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html \|title=Das V-Modell XT \|website=cio.bund.de \|publisher=[[Federal Office for Information Security]] (BMI) \|language=de}}
	* {{cite web \|url=https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html \|title=Using V Models for Testing \|date=11 November 2013 \|website=insights.sei.cmu.edu \|publisher=[[Software Engineering Institute]], [[Carnegie Mellon University]]}}		* {{cite web \|url=https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html \|title=Using V Models for Testing \|date=11 November 2013 \|website=insights.sei.cmu.edu \|publisher=[[Software Engineering Institute]], [[Carnegie Mellon University]]}}

	~~{{Systems Engineering}}~~

	[[Category:Articles with hatnote templates targeting a nonexistent page]]		[[Category:Articles with hatnote templates targeting a nonexistent page]]
Line 147:		Line 145:
	[[Category:Pages with broken file links]]		[[Category:Pages with broken file links]]
	[[Category:Pages with script errors]]		[[Category:Pages with script errors]]
			[[Category:Short description with empty Wikidata description]]
	[[Category:Sidebars with styles needing conversion]]		[[Category:Sidebars with styles needing conversion]]
	[[Category:Template documentation pages\|Documentation/doc]]		[[Category:Template documentation pages\|Documentation/doc]]

Manidh at 11:43, 29 July 2023

2023-07-29T11:43:23Z

@@ Line 133: / Line 133: @@
 {{Systems Engineering}}
+[[Category:Articles with hatnote templates targeting a nonexistent page]]
+[[Category:CS1 Deutsch-language sources (de)]]
-[[Category: Machine Translated Page]]
+[[Category:CS1 errors]]
 [[Category:Created On 09/07/2023]]
-[[Category:Vigyan Ready]]
+[[Category:Lua-based templates]]

Indicwiki: 17 revisions imported from :alpha:वी-मॉडल

2023-07-26T05:35:10Z

17 revisions imported from alpha:वी-मॉडल

← Older revision	Revision as of 11:05, 26 July 2023
(No difference)

alpha>Neeraja: added Category:Vigyan Ready using HotCat

2023-07-25T06:13:37Z

added Category:Vigyan Ready using HotCat

← Older revision		Revision as of 11:43, 25 July 2023
Line 139:		Line 139:
	[[Category: Machine Translated Page]]		[[Category: Machine Translated Page]]
	[[Category:Created On 09/07/2023]]		[[Category:Created On 09/07/2023]]
			[[Category:Vigyan Ready]]

alpha>Abhishek: /* वी-मॉडेल */

2023-07-20T10:00:04Z

वी-मॉडेल

← Older revision		Revision as of 15:30, 20 July 2023
Line 15:		Line 15:

	=== वी-मॉडेल ===		=== वी-मॉडेल ===
	वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः [[PRINCE2]] के समान है, किन्तु सॉफ्टवेयर विकास के लिए अधिक सीधे प्रासंगिक है।<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"], accessed July 10, 2020.</ref> वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि V के बाईं ओर के उत्पाद V के दाईं ओर को प्रस्तावित करने वाले उपयुक्त परीक्षण एवं एकीकरण संगठन द्वारा स्वीकार्य थे।<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{cite web		वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः [[PRINCE2]] के समान है, किन्तु सॉफ्टवेयर विकास के लिए अधिक सीधे प्रासंगिक है।<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"], accessed July 10, 2020.</ref> वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि V के बाईं ओर के उत्पाद V के दाईं ओर को प्रस्तावित करने वाले उपयुक्त परीक्षण एवं एकीकरण संगठन द्वारा स्वीकार्य थे।<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{cite web
	\| url = http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12		\| url = http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12
	\| title = Fundamentals of the V-Modell		\| title = Fundamentals of the V-Modell

alpha>Abhishek: Abhishek moved page बी-मॉडल to वी-मॉडल without leaving a redirect

2023-07-20T09:59:18Z

Abhishek moved page बी-मॉडल to वी-मॉडल without leaving a redirect

← Older revision	Revision as of 15:29, 20 July 2023
(No difference)

alpha>Sangeeta at 06:02, 20 July 2023

2023-07-20T06:02:20Z

alpha>Sangeeta at 05:57, 20 July 2023

2023-07-20T05:57:05Z

alpha>Sangeeta at 05:51, 20 July 2023

2023-07-20T05:51:02Z

← Older revision		Revision as of 11:21, 20 July 2023
Line 5:		Line 5:
	{{Software development process}}		{{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]] बताता है कि आवश्यकताओं को मान्य किया गया है, सत्य होने की पुष्टि की गई है एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।

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

	== प्रकार ==		== प्रकार ==

← Older revision		Revision as of 12:30, 8 September 2023
Line 1:		Line 1:
	{{Short description\|Graphic of a systems development lifecycle}}		{{Short description\|Graphic of a systems development lifecycle}}
	~~{{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>]]'''वी-मॉडल''' [[सिस्टम विकास जीवनचक्र]] का ग्राफिकल प्रतिनिधित्व है। इसका उपयोग कठोर विकास जीवनचक्र मॉडल एवं परियोजना प्रबंधन मॉडल प्रस्तुत करने के लिए किया जाता है। वी-मॉडल तीन व्यापक श्रेणियों, जर्मन वी-मॉडेल, सामान्य परीक्षण मॉडल एवं अमेरिकी सरकार मानक में आता है।<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>वी-मॉडल कम्प्यूटरीकृत सिस्टम सत्यापन फ्रेम, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणों का सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।
	~~सॉफ़्टवेयर विकास के लिए विशिष्ट संस्करण\|वी-मॉडल (सॉफ्टवेयर विकास)}}~~
	[[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>वी-मॉडल कम्प्यूटरीकृत सिस्टम सत्यापन फ्रेम, या परियोजना जीवन चक्र विकास के अंदर संबंधित डिलिवरेबल्स के संयोजन में उठाए जाने वाले मुख्य चरणों का सारांश देता है। यह उत्पाद विकास के समय की जाने वाली गतिविधियों एवं उत्पन्न होने वाले परिणामों का वर्णन करता है।

	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]] बताता है कि आवश्यकताओं को मान्य किया गया है, सत्य होने की पुष्टि की गई है एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।

← Older revision		Revision as of 11:32, 20 July 2023
Line 49:		Line 49:

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

	== वी-मॉडल विषय ==		== वी-मॉडल विषय ==
Line 59:		Line 59:
	सिस्टम इंजीनियरिंग प्रक्रिया (एसईपी) कठिन प्रणालियों की वित्त-प्रभावशीलता में सुधार के लिए मार्ग प्रदान करती है जैसा कि सिस्टम के मालिक द्वारा गर्भाधान से लेकर सेवानिवृत्ति तक, सिस्टम के पूर्ण जीवन में अनुभव किया जाता है।<ref name = "FHWA 05"/>		सिस्टम इंजीनियरिंग प्रक्रिया (एसईपी) कठिन प्रणालियों की वित्त-प्रभावशीलता में सुधार के लिए मार्ग प्रदान करती है जैसा कि सिस्टम के मालिक द्वारा गर्भाधान से लेकर सेवानिवृत्ति तक, सिस्टम के पूर्ण जीवन में अनुभव किया जाता है।<ref name = "FHWA 05"/>

	इसमें लक्ष्यों की प्रारंभिक एवं व्यापक पहचान, संचालन की अवधारणा जो उपयोगकर्ता की आवश्यकताओ एवं ऑपरेटिंग वातावरण, संपूर्ण एवं परीक्षण योग्य सिस्टम आवश्यकताओं, विस्तृत डिजाइन, कार्यान्वयन, कार्यान्वित सिस्टम की कठोर स्वीकृति परीक्षण का वर्णन करती है, जिससे यह सुनिश्चित किया जा सके कि यह बताई गई आवश्यकताओं को पूर्ण करती है (सिस्टम सत्यापन), लक्ष्यों को संबोधित करने (सिस्टम सत्यापन), प्रारम्भ संचालन एवं रखरखाव, समय के साथ सिस्टम अपग्रेड एवं अंततः सेवानिवृत्ति सम्मिलित है।<ref name = "FHWA 05"/><ref name=VPM/><ref name=INCOSE/><ref name=Original/>		इसमें लक्ष्यों की प्रारंभिक एवं व्यापक पहचान, संचालन की अवधारणा जो उपयोगकर्ता की आवश्यकताओ एवं ऑपरेटिंग वातावरण, संपूर्ण एवं परीक्षण योग्य सिस्टम आवश्यकताओं, विस्तृत डिजाइन, कार्यान्वयन, कार्यान्वित सिस्टम की कठोर स्वीकृति परीक्षण का वर्णन करती है, जिससे यह सुनिश्चित किया जा सके कि यह बताई गई आवश्यकताओं को पूर्ण करती है (सिस्टम सत्यापन), लक्ष्यों को संबोधित करने (सिस्टम सत्यापन), प्रारम्भ संचालन एवं रखरखाव, समय के साथ सिस्टम अपग्रेड एवं अंततः सेवानिवृत्ति सम्मिलित होती है।<ref name = "FHWA 05"/><ref name=VPM/><ref name=INCOSE/><ref name=Original/>

	यह प्रक्रिया आवश्यकताओं-संचालित डिजाइन एवं परीक्षण पर बल देती है। सभी डिज़ाइन तत्व एवं स्वीकृति परीक्षण या अधिक सिस्टम आवश्यकताओं के अनुरूप होने चाहिए एवं प्रत्येक आवश्यकता को अर्घ्य से अर्घ्य डिज़ाइन तत्व एवं स्वीकृति परीक्षण द्वारा संबोधित किया जाना चाहिए। ऐसी कठोरता यह सुनिश्चित करती है कि कुछ भी अनावश्यक रूप से नहीं किया जाए एवं जो कुछ आवश्यक है वह पूर्ण किया जाए।<ref name = "FHWA 05"/><ref name=VPM/>		यह प्रक्रिया आवश्यकताओं-संचालित डिजाइन एवं परीक्षण पर बल देती है। सभी डिज़ाइन तत्व एवं स्वीकृति परीक्षण या अधिक सिस्टम आवश्यकताओं के अनुरूप होने चाहिए एवं प्रत्येक आवश्यकता को अर्घ्य से अर्घ्य डिज़ाइन तत्व एवं स्वीकृति परीक्षण द्वारा संबोधित किया जाना चाहिए। ऐसी कठोरता यह सुनिश्चित करती है कि कुछ भी अनावश्यक रूप से नहीं किया जाए एवं जो कुछ आवश्यक है वह पूर्ण किया जाए।<ref name = "FHWA 05"/><ref name=VPM/>
Line 79:		Line 79:

	== अनुप्रयोग ==		== अनुप्रयोग ==
	[[Image:VPM3e Vee with detail.gif\|thumb\|320px\|ऑफ-कोर विकल्प (ऊपर एवं नीचे की ओर पुनरावृत्तियों एवं समय एवं परिपक्वता आयाम को दर्शाते हुए)। स्रोत - के. फ़ोर्सबर्ग एवं एच. मूज़ 2004<ref name=VPM/><ref name=Original/>]]वी-मॉडल का उपयोग जर्मन संघीय प्रशासन के अंदर सॉफ्टवेयर विकास प्रक्रिया को विनियमित करने के लिए किया जाता है। आजकल यह अभी भी जर्मन संघीय प्रशासन एवं रक्षा परियोजनाओं के साथ-साथ क्षेत्र के सॉफ्टवेयर ~~डेवलपर्स~~ के लिए मानक है।		[[Image:VPM3e Vee with detail.gif\|thumb\|320px\|ऑफ-कोर विकल्प (ऊपर एवं नीचे की ओर पुनरावृत्तियों एवं समय एवं परिपक्वता आयाम को दर्शाते हुए)। स्रोत - के. फ़ोर्सबर्ग एवं एच. मूज़ 2004<ref name=VPM/><ref name=Original/>]]वी-मॉडल का उपयोग जर्मन संघीय प्रशासन के अंदर सॉफ्टवेयर विकास प्रक्रिया को विनियमित करने के लिए किया जाता है। आजकल यह अभी भी जर्मन संघीय प्रशासन एवं रक्षा परियोजनाओं के साथ-साथ क्षेत्र के सॉफ्टवेयर विकासक्स के लिए मानक है।

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

← Older revision		Revision as of 11:27, 20 July 2023
Line 15:		Line 15:

	=== वी-मॉडेल ===		=== वी-मॉडेल ===
	वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः [[PRINCE2]] के समान है, किन्तु सॉफ्टवेयर विकास के लिए अधिक सीधे प्रासंगिक है।<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"], accessed July 10, 2020.</ref> वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि वी के बाईं ओर के उत्पाद वी के दाईं ओर को प्रस्तावित करने वाले उपयुक्त परीक्षण एवं एकीकरण संगठन द्वारा स्वीकार्य थे।<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{cite web		वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः [[PRINCE2]] के समान है, किन्तु सॉफ्टवेयर विकास के लिए अधिक सीधे प्रासंगिक है।<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"], accessed July 10, 2020.</ref> वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि V के बाईं ओर के उत्पाद V के दाईं ओर को प्रस्तावित करने वाले उपयुक्त परीक्षण एवं एकीकरण संगठन द्वारा स्वीकार्य थे।<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{cite web
	\| url = http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12		\| url = http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12
	\| title = Fundamentals of the V-Modell		\| title = Fundamentals of the V-Modell
	\| access-date = 14 Apr 2016}}</ref><ref>{{cite web		\| access-date = 14 Apr 2016}}</ref><ref>{{cite web
	\| url = http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1-eng/Dokumentation/pdf/V-Modell-XT-eng-Teil1.pdf		\| url = http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1-eng/Dokumentation/pdf/V-Modell-XT-eng-Teil1.pdf
	\| title = V-Modell XT, Part 1: Fundamentals of the V-Modell		\| title = V-Modell XT, Part 1: Fundamentals of the V-Modell
	\| access-date = 14 Apr 2016}}</ref>		\| access-date = 14 Apr 2016}}</ref>

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

	समाज में परीक्षण समुदाय में, वी-मॉडल को व्यापक रूप से सॉफ्टवेयर विकास प्रक्रिया के अस्पष्ट चित्रण के रूप में देखा जाता है जैसा कि सॉफ्टवेयर परीक्षकों के लिए [[अंतर्राष्ट्रीय सॉफ्टवेयर परीक्षण योग्यता बोर्ड]] फाउंडेशन पाठ्यक्रम में वर्णित है।<ref>[http://www.istqb.org/downloads/viewdownload/16/15.html "International Software Testing Qualifications Board – Foundation Level Syllabus"], accessed January 9, 2013.</ref> इस मॉडल की कोई परिभाषा नहीं है, जो वी-मॉडल (सॉफ़्टवेयर विकास) पर वैकल्पिक लेख में अधिक सामान्य रूप से सम्मिलित है।		समाज में परीक्षण समुदाय में, वी-मॉडल को व्यापक रूप से सॉफ्टवेयर विकास प्रक्रिया के अस्पष्ट चित्रण के रूप में देखा जाता है, जैसा कि सॉफ्टवेयर परीक्षकों के लिए [[अंतर्राष्ट्रीय सॉफ्टवेयर परीक्षण योग्यता बोर्ड]] फाउंडेशन पाठ्यक्रम में वर्णित है।<ref>[http://www.istqb.org/downloads/viewdownload/16/15.html "International Software Testing Qualifications Board – Foundation Level Syllabus"], accessed January 9, 2013.</ref> इस मॉडल की कोई परिभाषा नहीं है, जो वी-मॉडल (सॉफ़्टवेयर विकास) पर वैकल्पिक लेख में अधिक सामान्य रूप से सम्मिलित है।

	=== अमेरिकी सरकार मानक ===		=== अमेरिकी सरकार मानक ===
	अमेरिका में सरकारी मानक वी-मॉडल भी है जो लगभग 20 ~~साल~~ प्राचीन है। ~~इसका दायरा~~ संकीर्ण सिस्टम विकास जीवनचक्र मॉडल है, किन्तु अधिकांश यूके चिकित्सकों एवं परीक्षकों द्वारा वी-मॉडल द्वारा समझे जाने की अपेक्षा में कहीं अधिक विस्तृत एवं अधिक कठोर है।<ref>{{cite web \| url=http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf \| title=इंटेलिजेंट ट्रांसपोर्टेशन सिस्टम के लिए सिस्टम इंजीनियरिंग\| publisher=US Dept. of Transportation\|page=10\| access-date=June 9, 2007}}</ref><ref>[http://www.fhwa.dot.gov/cadiv/segb/index.htm "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS"], accessed January 9, 2013.</ref><ref name=VPM>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.</ref><ref name=INCOSE>International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref>{{cite web		अमेरिका में सरकारी मानक वी-मॉडल भी है, जो लगभग 20 वर्ष प्राचीन है। इसकी सीमा संकीर्ण सिस्टम विकास जीवनचक्र मॉडल होती है, किन्तु अधिकांश यूके चिकित्सकों एवं परीक्षकों द्वारा वी-मॉडल द्वारा समझे जाने की अपेक्षा में कहीं अधिक विस्तृत एवं अधिक कठोर है।<ref>{{cite web \| url=http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf \| title=इंटेलिजेंट ट्रांसपोर्टेशन सिस्टम के लिए सिस्टम इंजीनियरिंग\| publisher=US Dept. of Transportation\|page=10\| access-date=June 9, 2007}}</ref><ref>[http://www.fhwa.dot.gov/cadiv/segb/index.htm "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS"], accessed January 9, 2013.</ref><ref name=VPM>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.</ref><ref name=INCOSE>International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref>{{cite web
	\| url = http://www.dau.mil/pubscats/PubsCats/AR%20Journal/arj53/Redshaw53.pdf		\| url = http://www.dau.mil/pubscats/PubsCats/AR%20Journal/arj53/Redshaw53.pdf
	\| title = BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION		\| title = BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION
Line 39:		Line 39:
	{{Main\|सत्यापन एवं सत्यापन\|सत्यापन (दवा निर्माण)}}		{{Main\|सत्यापन एवं सत्यापन\|सत्यापन (दवा निर्माण)}}

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

	प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए गाइड, जिसे [[IEEE\|आईईईई]] द्वारा मानक के रूप में भी ~~अपनाया~~ गया है (इनकोस, सिस्टम इंजीनियरिंग रिसर्च काउंसिल एसईआरसी एवं आईईईई कंप्यूटर सोसाइटी द्वारा संयुक्त रूप से बनाए रखा गया है) उन्हें अपने चौथे संस्करण में निम्नानुसार परिभाषित करता है:<ref name="pmboked4">{{cite book \| title = आईईईई गाइड--प्रोजेक्ट मैनेजमेंट इंस्टीट्यूट (पीएमआई) मानक को अपनाना, प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए एक गाइड (पीएमबीओके गाइड)--चौथा संस्करण\| last = IEEE \| journal = IEEE P1490/D1, May 2011 \| date = June 2011 \| author-link = IEEE \| url = https://ieeexplore.ieee.org/document/5937011 \| access-date = May 25, 2021 \| doi = 10.1109/IEEESTD.2011.6086685 \| page=452 \| isbn = 978-0-7381-6817-3 }}</ref>		प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए गाइड, जिसे [[IEEE\|आईईईई]] द्वारा मानक के रूप में भी स्वीकार किया गया है (इनकोस, सिस्टम इंजीनियरिंग रिसर्च काउंसिल एसईआरसी एवं आईईईई कंप्यूटर सोसाइटी द्वारा संयुक्त रूप से बनाए रखा गया है) उन्हें अपने चौथे संस्करण में निम्नानुसार परिभाषित करता है:<ref name="pmboked4">{{cite book \| title = आईईईई गाइड--प्रोजेक्ट मैनेजमेंट इंस्टीट्यूट (पीएमआई) मानक को अपनाना, प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए एक गाइड (पीएमबीओके गाइड)--चौथा संस्करण\| last = IEEE \| journal = IEEE P1490/D1, May 2011 \| date = June 2011 \| author-link = IEEE \| url = https://ieeexplore.ieee.org/document/5937011 \| access-date = May 25, 2021 \| doi = 10.1109/IEEESTD.2011.6086685 \| page=452 \| isbn = 978-0-7381-6817-3 }}</ref>
	*सत्यापन. यह आश्वासन कि कोई उत्पाद, सेवा या सिस्टम ग्राहक एवं अन्य पहचाने गए हितधारकों की ~~जरूरतों~~ को पूर्ण करती है। इसमें प्रायः बाहरी ग्राहकों के साथ स्वीकृति एवं उपयुक्तता सम्मिलित होती है। सत्यापन ~~से अपेक्षा~~ करें।		*सत्यापन.यह आश्वासन कि कोई उत्पाद, सेवा या सिस्टम ग्राहक एवं अन्य पहचाने गए हितधारकों की आवश्यकताओ को पूर्ण करती है। इसमें प्रायः बाहरी ग्राहकों के साथ स्वीकृति एवं उपयुक्तता सम्मिलित होती है। "सत्यापन के साथ समानता करें।"
	* सत्यापन. कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई ~~शर्त~~ का अनुपालन करता है या नहीं करता है। यह प्रायः आंतरिक प्रक्रिया होती है। ''सत्यापन~~'' से अपेक्षा~~ करें।		* सत्यापन.कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई प्रतिज्ञा का अनुपालन करता है या नहीं करता है। यह प्रायः आंतरिक प्रक्रिया होती है। "सत्यापन के साथ समानता करें।"

	== उद्देश्य ==		== उद्देश्य ==