वी-मॉडल: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Graphic of a systems development lifecycle}} {{For|the version specific to software development|V-model (software development)}} Image:Systems Engineerin...")
 
No edit summary
Line 4: Line 4:
{{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]] बताता है कि आवश्यकताओं को मान्य किया गया है - सत्य होने की पुष्टि की गई है - और अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूरा करता है।


मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप सही चीज़ बना रहे हैं? और सत्यापन के साथ कि क्या आप इसे सही ढंग से बना रहे हैं?
मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप सही चीज़ बना रहे हैं? और सत्यापन के साथ कि क्या आप इसे सही ढंग से बना रहे हैं?
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> वी प्रतिनिधित्व का उपयोग करने की मुख्य विशेषता यह प्रमाण की आवश्यकता थी कि वी के बाईं ओर के उत्पाद वी के दाईं ओर को लागू करने वाले उपयुक्त परीक्षण और ीकरण संगठन द्वारा स्वीकार्य थे।<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 साल पुराना है{{when|date=January 2023}} अपने जर्मन समकक्ष की तरह। इसका दायरा एक संकीर्ण सिस्टम विकास जीवनचक्र मॉडल है, लेकिन अधिकांश यूके चिकित्सकों और परीक्षकों द्वारा वी-मॉडल द्वारा समझे जाने की तुलना में कहीं अधिक विस्तृत और अधिक कठोर है।<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 साल पुराना है{{when|date=January 2023}} अपने जर्मन समकक्ष की तरह। इसका दायरा संकीर्ण सिस्टम विकास जीवनचक्र मॉडल है, लेकिन अधिकांश यूके चिकित्सकों और परीक्षकों द्वारा वी-मॉडल द्वारा समझे जाने की तुलना में कहीं अधिक विस्तृत और अधिक कठोर है।<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 35: Line 35:
| title = Using V Models for Testing  
| title = Using V Models for Testing  
| access-date = 14 Apr 2016}}</ref>
| access-date = 14 Apr 2016}}</ref>


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


प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए एक गाइड, जिसे [[IEEE]] द्वारा एक मानक के रूप में भी अपनाया गया है (INCOSE, सिस्टम इंजीनियरिंग रिसर्च काउंसिल SERC और 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]] द्वारा मानक के रूप में भी अपनाया गया है (INCOSE, सिस्टम इंजीनियरिंग रिसर्च काउंसिल SERC और 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>
*सत्यापन. यह आश्वासन कि कोई उत्पाद, सेवा या प्रणाली ग्राहक और अन्य पहचाने गए हितधारकों की जरूरतों को पूरा करती है। इसमें अक्सर बाहरी ग्राहकों के साथ स्वीकृति और उपयुक्तता शामिल होती है। ''सत्यापन'' से तुलना करें।
*सत्यापन. यह आश्वासन कि कोई उत्पाद, सेवा या प्रणाली ग्राहक और अन्य पहचाने गए हितधारकों की जरूरतों को पूरा करती है। इसमें अक्सर बाहरी ग्राहकों के साथ स्वीकृति और उपयुक्तता शामिल होती है। ''सत्यापन'' से तुलना करें।
* सत्यापन. कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई शर्त का अनुपालन करता है या नहीं, इसका मूल्यांकन। यह अक्सर एक आंतरिक प्रक्रिया होती है. ''सत्यापन'' से तुलना करें।
* सत्यापन. कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई शर्त का अनुपालन करता है या नहीं, इसका मूल्यांकन। यह अक्सर आंतरिक प्रक्रिया होती है. ''सत्यापन'' से तुलना करें।


== उद्देश्य ==
== उद्देश्य ==
Line 50: Line 49:


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


Line 58: Line 57:


=== सिस्टम इंजीनियरिंग और सत्यापन ===
=== सिस्टम इंजीनियरिंग और सत्यापन ===
सिस्टम इंजीनियरिंग प्रक्रिया (एसईपी) जटिल प्रणालियों की लागत-प्रभावशीलता में सुधार के लिए एक मार्ग प्रदान करती है जैसा कि सिस्टम के मालिक द्वारा गर्भाधान से लेकर सेवानिवृत्ति तक, सिस्टम के पूरे जीवन में अनुभव किया जाता है।<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 = "FHWA 05"/><ref name=VPM/><ref name=INCOSE/><ref name=Original/>


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


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


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


* जर्मन वी-मॉडल मूल रूप से म्यूनिख के पास ओटोब्रून में आईएबीजी द्वारा, संघीय रक्षा मंत्रालय के लिए कोबलेनज़ में रक्षा प्रौद्योगिकी और खरीद के संघीय कार्यालय के सहयोग से विकसित किया गया था। इसे 1992 की गर्मियों में नागरिक सार्वजनिक प्राधिकरण डोमेन के लिए संघीय आंतरिक मंत्रालय द्वारा अपने अधिकार में ले लिया गया था।<ref name=GermanOriginal>{{cite web|url=http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|title=वी-मॉडल जीवनचक्र प्रक्रिया मॉडल|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20160303204644/http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|archive-date=March 3, 2016|url-status=dead|df=mdy-all}}</ref>
* जर्मन वी-मॉडल मूल रूप से म्यूनिख के पास ओटोब्रून में आईएबीजी द्वारा, संघीय रक्षा मंत्रालय के लिए कोबलेनज़ में रक्षा प्रौद्योगिकी और खरीद के संघीय कार्यालय के सहयोग से विकसित किया गया था। इसे 1992 की गर्मियों में नागरिक सार्वजनिक प्राधिकरण डोमेन के लिए संघीय आंतरिक मंत्रालय द्वारा अपने अधिकार में ले लिया गया था।<ref name=GermanOriginal>{{cite web|url=http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|title=वी-मॉडल जीवनचक्र प्रक्रिया मॉडल|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20160303204644/http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|archive-date=March 3, 2016|url-status=dead|df=mdy-all}}</ref>
* यूएस वी-मॉडल, जैसा कि 1991 में [[सिस्टम इंजीनियरिंग पर अंतर्राष्ट्रीय परिषद]] (एनसीओएसई; अब 1995 में आईएनसीओएसई) की कार्यवाही में प्रलेखित किया गया है।<ref name=Original/>हार्डवेयर, सॉफ्टवेयर और मानव संपर्क से जुड़े उपग्रह प्रणालियों के लिए विकसित किया गया था।
* यूएस वी-मॉडल, जैसा कि 1991 में [[सिस्टम इंजीनियरिंग पर अंतर्राष्ट्रीय परिषद]] (एनसीओएसई; अब 1995 में आईएनसीओएसई) की कार्यवाही में प्रलेखित किया गया है।<ref name=Original/>हार्डवेयर, सॉफ्टवेयर और मानव संपर्क से जुड़े उपग्रह प्रणालियों के लिए विकसित किया गया था।
* वी-मॉडल पहली बार एफएए एडवांस्ड ऑटोमेशन सिस्टम (एएएस) कार्यक्रम के पूर्व-प्रस्ताव प्रयास के हिस्से के रूप में [[ह्यूजेस विमान]] में लगभग 1982 में दिखाई दिया। इसने अंततः ह्यूजेस एएएस डिज़ाइन प्रतियोगिता चरण (डीसीपी) प्रस्ताव के लिए परीक्षण रणनीति बनाई। इसे परीक्षण और एकीकरण दृष्टिकोण को दिखाने के लिए बनाया गया था जो सॉफ़्टवेयर में गुप्त दोषों को सामने लाने की नई चुनौतियों से प्रेरित था। अव्यक्त दोष का पता लगाने के इस नए स्तर की आवश्यकता हवाई यातायात नियंत्रक की सोच और योजना प्रक्रियाओं को स्वचालित करना शुरू करने के लक्ष्य से प्रेरित थी, जैसा कि स्वचालित एनरूट हवाई यातायात नियंत्रण (एईआरए) कार्यक्रम द्वारा कल्पना की गई थी। वी के इतने शक्तिशाली होने का कारण सभी पाठ और विश्लेषण को बहुआयामी छवियों के साथ जोड़ने की ह्यूजेस संस्कृति से आता है। यह प्रकाशनों के अनुक्रमिक विषयगत संगठन (STOP) की नींव थी। <ref name="scribd">{{cite web |url=https://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-url=https://web.archive.org/web/20080203133138/http://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-date=February 3, 2008 |url-status=dead |title=प्रकाशनों का अनुक्रमिक विषयगत संगठन (STOP)|access-date=December 24, 2015 |df=mdy-all }}</ref> 1963 में ह्यूजेस द्वारा बनाया गया और 1985 में [[हावर्ड ह्यूजेस मेडिकल इंस्टीट्यूट]] द्वारा ह्यूजेस का विनिवेश होने तक इसका उपयोग किया गया।<ref>{{cite book | title = क्रिएटिव सिस्टम इंजीनियरिंग से सतत विकास संभव|isbn=978-0615216300|last1=Sobkiw|first1=Walter|date=2008-01-01}}</ref>
* वी-मॉडल पहली बार एफएए एडवांस्ड ऑटोमेशन सिस्टम (एएएस) कार्यक्रम के पूर्व-प्रस्ताव प्रयास के हिस्से के रूप में [[ह्यूजेस विमान]] में लगभग 1982 में दिखाई दिया। इसने अंततः ह्यूजेस एएएस डिज़ाइन प्रतियोगिता चरण (डीसीपी) प्रस्ताव के लिए परीक्षण रणनीति बनाई। इसे परीक्षण और ीकरण दृष्टिकोण को दिखाने के लिए बनाया गया था जो सॉफ़्टवेयर में गुप्त दोषों को सामने लाने की नई चुनौतियों से प्रेरित था। अव्यक्त दोष का पता लगाने के इस नए स्तर की आवश्यकता हवाई यातायात नियंत्रक की सोच और योजना प्रक्रियाओं को स्वचालित करना शुरू करने के लक्ष्य से प्रेरित थी, जैसा कि स्वचालित एनरूट हवाई यातायात नियंत्रण (एईआरए) कार्यक्रम द्वारा कल्पना की गई थी। वी के इतने शक्तिशाली होने का कारण सभी पाठ और विश्लेषण को बहुआयामी छवियों के साथ जोड़ने की ह्यूजेस संस्कृति से आता है। यह प्रकाशनों के अनुक्रमिक विषयगत संगठन (STOP) की नींव थी। <ref name="scribd">{{cite web |url=https://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-url=https://web.archive.org/web/20080203133138/http://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-date=February 3, 2008 |url-status=dead |title=प्रकाशनों का अनुक्रमिक विषयगत संगठन (STOP)|access-date=December 24, 2015 |df=mdy-all }}</ref> 1963 में ह्यूजेस द्वारा बनाया गया और 1985 में [[हावर्ड ह्यूजेस मेडिकल इंस्टीट्यूट]] द्वारा ह्यूजेस का विनिवेश होने तक इसका उपयोग किया गया।<ref>{{cite book | title = क्रिएटिव सिस्टम इंजीनियरिंग से सतत विकास संभव|isbn=978-0615216300|last1=Sobkiw|first1=Walter|date=2008-01-01}}</ref>
* अमेरिकी रक्षा विभाग [[ प्रणाली अभियांत्रिकी ]] प्रक्रिया इंटरैक्शन को वी-मॉडल संबंध में रखता है।<ref>{{cite web  
* अमेरिकी रक्षा विभाग [[ प्रणाली अभियांत्रिकी ]] प्रक्रिया इंटरैक्शन को वी-मॉडल संबंध में रखता है।<ref>{{cite web  
| url = http://www.dau.mil/pubscats/PubsCats/atl/2006_03_04/mar-apr06.pdf
| url = http://www.dau.mil/pubscats/PubsCats/atl/2006_03_04/mar-apr06.pdf
Line 98: Line 95:
इसे अब वाणिज्यिक और साथ ही रक्षा कार्यक्रमों में व्यापक अनुप्रयोग मिल गया है। इसका प्राथमिक उपयोग परियोजना प्रबंधन में है<ref name=VPM/><ref name=INCOSE/>और पूरे प्रोजेक्ट जीवनचक्र के दौरान।
इसे अब वाणिज्यिक और साथ ही रक्षा कार्यक्रमों में व्यापक अनुप्रयोग मिल गया है। इसका प्राथमिक उपयोग परियोजना प्रबंधन में है<ref name=VPM/><ref name=INCOSE/>और पूरे प्रोजेक्ट जीवनचक्र के दौरान।


यूएस वी-मॉडल की एक मूलभूत विशेषता यह है कि समय और परिपक्वता बाएं से दाएं की ओर चलती है और कोई भी समय में पीछे नहीं जा सकता है। जैसा कि चित्र में दिखाया गया है, सभी पुनरावृत्ति सिस्टम पदानुक्रम में उच्च या निम्न स्तर तक एक ऊर्ध्वाधर रेखा के साथ होती है।<ref name=VPM/><ref name=INCOSE/><ref name=Original/>  यह मॉडल का एक महत्वपूर्ण पहलू साबित हुआ है। मॉडल के दोहरे-वी अवधारणा के विस्तार को संदर्भ में माना जाता है।<ref name=VPM/>
यूएस वी-मॉडल की मूलभूत विशेषता यह है कि समय और परिपक्वता बाएं से दाएं की ओर चलती है और कोई भी समय में पीछे नहीं जा सकता है। जैसा कि चित्र में दिखाया गया है, सभी पुनरावृत्ति सिस्टम पदानुक्रम में उच्च या निम्न स्तर तक ऊर्ध्वाधर रेखा के साथ होती है।<ref name=VPM/><ref name=INCOSE/><ref name=Original/>  यह मॉडल का महत्वपूर्ण पहलू साबित हुआ है। मॉडल के दोहरे-वी अवधारणा के विस्तार को संदर्भ में माना जाता है।<ref name=VPM/>


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


== लाभ ==
== लाभ ==
अन्य सिस्टम विकास मॉडल के सामने वी-मॉडल के ये फायदे हैं:
अन्य सिस्टम विकास मॉडल के सामने वी-मॉडल के ये फायदे हैं:


* वी-मॉडल के उपयोगकर्ता वी-मॉडल के विकास और रखरखाव में भाग लेते हैं। एक परिवर्तन नियंत्रण बोर्ड सार्वजनिक रूप से वी-मॉडल का रखरखाव करता है। परिवर्तन नियंत्रण बोर्ड हर दिन से लेकर साप्ताहिक तक कहीं भी मिलता है और सिस्टम विकास और परीक्षण के दौरान प्राप्त सभी परिवर्तन अनुरोधों को संसाधित करता है।<ref name="VModelChange">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|title=वी-मॉडल का और विकास (टूटी हुई कड़ी)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110423005924/http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|archive-date=April 23, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>
* वी-मॉडल के उपयोगकर्ता वी-मॉडल के विकास और रखरखाव में भाग लेते हैं। परिवर्तन नियंत्रण बोर्ड सार्वजनिक रूप से वी-मॉडल का रखरखाव करता है। परिवर्तन नियंत्रण बोर्ड हर दिन से लेकर साप्ताहिक तक कहीं भी मिलता है और सिस्टम विकास और परीक्षण के दौरान प्राप्त सभी परिवर्तन अनुरोधों को संसाधित करता है।<ref name="VModelChange">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|title=वी-मॉडल का और विकास (टूटी हुई कड़ी)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110423005924/http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|archive-date=April 23, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>
* वी-मॉडल किसी गतिविधि और उसके कार्य चरणों को कैसे लागू किया जाए, इस पर ठोस सहायता प्रदान करता है, एक कार्य चरण को पूरा करने के लिए आवश्यक घटनाओं को स्पष्ट रूप से परिभाषित करता है: प्रत्येक गतिविधि स्कीमा में गतिविधि के निर्देश, सिफारिशें और विस्तृत स्पष्टीकरण शामिल होते हैं।<ref name="VModelActivities">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|title=वी-मॉडल के गतिविधि मॉडल का अवलोकन (टूटी हुई कड़ी)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110719043340/http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|archive-date=July 19, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>
* वी-मॉडल किसी गतिविधि और उसके कार्य चरणों को कैसे लागू किया जाए, इस पर ठोस सहायता प्रदान करता है, कार्य चरण को पूरा करने के लिए आवश्यक घटनाओं को स्पष्ट रूप से परिभाषित करता है: प्रत्येक गतिविधि स्कीमा में गतिविधि के निर्देश, सिफारिशें और विस्तृत स्पष्टीकरण शामिल होते हैं।<ref name="VModelActivities">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|title=वी-मॉडल के गतिविधि मॉडल का अवलोकन (टूटी हुई कड़ी)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110719043340/http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|archive-date=July 19, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>
 


== सीमाएँ ==
== सीमाएँ ==
निम्नलिखित पहलुओं को वी-मॉडल द्वारा कवर नहीं किया गया है, उन्हें अतिरिक्त रूप से विनियमित किया जाना चाहिए, या वी-मॉडल को तदनुसार अनुकूलित किया जाना चाहिए:<ref name=VModelLimits1>{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|title=वी मॉडल की सीमाएं|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20110521043950/http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|archive-date=May 21, 2011|url-status=dead|df=mdy-all}}</ref><ref name=VModelLimits2>Christian Bucanac, [http://www.bucanac.com/documents/The_V-Model.pdf The V-Model]</ref>
निम्नलिखित पहलुओं को वी-मॉडल द्वारा कवर नहीं किया गया है, उन्हें अतिरिक्त रूप से विनियमित किया जाना चाहिए, या वी-मॉडल को तदनुसार अनुकूलित किया जाना चाहिए:<ref name=VModelLimits1>{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|title=वी मॉडल की सीमाएं|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20110521043950/http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|archive-date=May 21, 2011|url-status=dead|df=mdy-all}}</ref><ref name=VModelLimits2>Christian Bucanac, [http://www.bucanac.com/documents/The_V-Model.pdf The V-Model]</ref>
* सेवाओं के लिए अनुबंध रखना विनियमित नहीं है।
* सेवाओं के लिए अनुबंध रखना विनियमित नहीं है।
* सिस्टम के संचालन, रखरखाव, मरम्मत और निपटान का संगठन और निष्पादन वी-मॉडल द्वारा कवर नहीं किया जाता है। हालाँकि, इन कार्यों के लिए एक अवधारणा की योजना और तैयारी को वी-मॉडल में विनियमित किया जाता है।
* सिस्टम के संचालन, रखरखाव, मरम्मत और निपटान का संगठन और निष्पादन वी-मॉडल द्वारा कवर नहीं किया जाता है। हालाँकि, इन कार्यों के लिए अवधारणा की योजना और तैयारी को वी-मॉडल में विनियमित किया जाता है।
* वी-मॉडल पूरे संगठन के बजाय एक परियोजना के भीतर सॉफ्टवेयर विकास को संबोधित करता है।
* वी-मॉडल पूरे संगठन के बजाय परियोजना के भीतर सॉफ्टवेयर विकास को संबोधित करता है।


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

Revision as of 20:01, 19 July 2023

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