वी-मॉडल: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(9 intermediate revisions by 6 users not shown)
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]] बताता है कि आवश्यकताओं को मान्य किया गया है - सत्य होने की पुष्टि की गई है - एवं अंतिम उत्पाद को यह सुनिश्चित करने के लिए सत्यापित किया गया है कि यह उन आवश्यकताओं को पूर्ण करता है।
मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप उचित वस्तु बना रहे हैं? एवं सत्यापन के साथ कि क्या आप इसे उचित रूप से बना रहे हैं?
 
मान्यता इस प्रश्न के साथ व्यक्त की जा सकती है कि क्या आप उचित चीज़ बना रहे हैं? एवं सत्यापन के साथ कि क्या आप इसे उचित उचित से बना रहे हैं?


== प्रकार ==
== प्रकार ==
Line 15: Line 10:


=== वी-मॉडेल ===
=== वी-मॉडेल ===
वी-मॉडेल जर्मन सरकार की आधिकारिक परियोजना प्रबंधन पद्धति है। यह सामान्यतः [[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 34:
{{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>
*सत्यापन. यह आश्वासन कि कोई उत्पाद, सेवा या सिस्टम ग्राहक एवं अन्य पहचाने गए हितधारकों की जरूरतों को पूर्ण करती है। इसमें प्रायः बाहरी ग्राहकों के साथ स्वीकृति एवं उपयुक्तता सम्मिलित होती है। सत्यापन से अपेक्षा करें।
*सत्यापन.यह आश्वासन कि कोई उत्पाद, सेवा या सिस्टम ग्राहक एवं अन्य पहचाने गए हितधारकों की आवश्यकताओ को पूर्ण करती है। इसमें प्रायः बाहरी ग्राहकों के साथ स्वीकृति एवं उपयुक्तता सम्मिलित होती है। "सत्यापन के साथ समानता करें।"
* सत्यापन. कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई शर्त का अनुपालन करता है या नहीं करता है। यह प्रायः आंतरिक प्रक्रिया होती है। ''सत्यापन'' से अपेक्षा करें।
* सत्यापन.कोई उत्पाद, सेवा या सिस्टम किसी विनियमन, आवश्यकता, विनिर्देश या लगाई गई प्रतिज्ञा का अनुपालन करता है या नहीं करता है। यह प्रायः आंतरिक प्रक्रिया होती है। "सत्यापन के साथ समानता करें।"


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


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


== वी-मॉडल विषय ==
== वी-मॉडल विषय ==
Line 59: Line 54:
सिस्टम इंजीनियरिंग प्रक्रिया (एसईपी) कठिन प्रणालियों की वित्त-प्रभावशीलता में सुधार के लिए मार्ग प्रदान करती है जैसा कि सिस्टम के मालिक द्वारा गर्भाधान से लेकर सेवानिवृत्ति तक, सिस्टम के पूर्ण जीवन में अनुभव किया जाता है।<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 74:


== अनुप्रयोग ==
== अनुप्रयोग ==
[[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 के दशक के अंत में जर्मनी एवं संयुक्त राज्य अमेरिका में  साथ, किन्तु स्वतंत्र रूप से विकसित की गई थी:
Line 132: Line 127:
* {{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: सॉफ्टवेयर परियोजना प्रबंधन]] [[Category: प्रणाली अभियांत्रिकी]]  
[[Category:CS1 Deutsch-language sources (de)]]
 
[[Category:CS1 errors]]
 
[[Category:CS1 maint]]
 
[[Category:Collapse templates]]
[[Category: Machine Translated Page]]
[[Category:Commons category link is locally defined]]
[[Category:Created On 09/07/2023]]
[[Category:Created On 09/07/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists]]
[[Category:Pages with broken file links]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Sidebars with styles needing conversion]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Translated in Hindi]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates generating microformats]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that are not mobile friendly]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Webarchive template wayback links]]
[[Category:Wikipedia metatemplates]]
[[Category:प्रणाली अभियांत्रिकी]]
[[Category:सॉफ्टवेयर परियोजना प्रबंधन]]

Latest revision as of 12:30, 8 September 2023

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

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

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

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

प्रकार

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

वी-मॉडेल

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

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

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

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

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

सत्यापन के प्रति सत्यापन

Main articles: सत्यापन एवं सत्यापन and सत्यापन (दवा निर्माण)

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

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

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

उद्देश्य

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

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

वी-मॉडल विषय

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

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

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

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

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

दो धाराएँ

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

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

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

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

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

  • स्थापना योग्यता (IQ)
  • परिचालन योग्यता (OQ)
  • प्रदर्शन योग्यता (PQ)

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

अनुप्रयोग

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

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

वी-मॉडल की अवधारणा 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. ↑ 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.
  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.
  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. ↑ "एसई वीईई". SEOR, George Mason University. Archived from the original on October 18, 2007. Retrieved May 26, 2007.
  7. ↑ 7.0 7.1 7.2 7.3 7.4 Forsberg, K. and Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" Archived 2009-02-27 at the Wayback Machine, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991
  8. ↑ "V-Modell site (in German)", accessed July 10, 2020.
  9. ↑ German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992
  10. ↑ "Fundamentals of the V-Modell". Retrieved 14 Apr 2016.
  11. ↑ "V-Modell XT, Part 1: Fundamentals of the V-Modell" (PDF). Retrieved 14 Apr 2016.
  12. ↑ "International Software Testing Qualifications Board – Foundation Level Syllabus", accessed January 9, 2013.
  13. ↑ "इंटेलिजेंट ट्रांसपोर्टेशन सिस्टम के लिए सिस्टम इंजीनियरिंग" (PDF). US Dept. of Transportation. p. 10. Retrieved June 9, 2007.
  14. ↑ "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS", accessed January 9, 2013.
  15. ↑ "BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION" (PDF). Retrieved 14 Apr 2016.
  16. ↑ "Using V Models for Testing". Retrieved 14 Apr 2016.
  17. ↑ IEEE (June 2011). आईईईई गाइड--प्रोजेक्ट मैनेजमेंट इंस्टीट्यूट (पीएमआई) मानक को अपनाना, प्रोजेक्ट मैनेजमेंट बॉडी ऑफ नॉलेज के लिए एक गाइड (पीएमबीओके गाइड)--चौथा संस्करण. p. 452. doi:10.1109/IEEESTD.2011.6086685. ISBN 978-0-7381-6817-3. Retrieved May 25, 2021. {{cite book}}: |journal= ignored (help)
  18. ↑ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
  19. ↑ "वी-मॉडल जीवनचक्र प्रक्रिया मॉडल". v-modell.iabg.de. Archived from the original on March 3, 2016. Retrieved December 24, 2015.
  20. ↑ "प्रकाशनों का अनुक्रमिक विषयगत संगठन (STOP)". Archived from the original on February 3, 2008. Retrieved December 24, 2015.
  21. ↑ Sobkiw, Walter (2008-01-01). क्रिएटिव सिस्टम इंजीनियरिंग से सतत विकास संभव. ISBN 978-0615216300.
  22. ↑ "A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions" (PDF). Defense AT&L. Apr 2006. p. 51. Retrieved 7 Apr 2016.
  23. ↑ "वी-मॉडल का और विकास (टूटी हुई कड़ी)". v-modell.iabg.de. Archived from the original on April 23, 2011. Retrieved December 24, 2015.
  24. ↑ "वी-मॉडल के गतिविधि मॉडल का अवलोकन (टूटी हुई कड़ी)". v-modell.iabg.de. Archived from the original on July 19, 2011. Retrieved December 24, 2015.
  25. ↑ "वी मॉडल की सीमाएं". v-modell.iabg.de. Archived from the original on May 21, 2011. Retrieved December 24, 2015.
  26. ↑ Christian Bucanac, The V-Model


बाहरी संबंध

Wikimedia Commons has media related to V-models.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=वी-मॉडल&oldid=255991’