जलप्रपात मॉडल: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Modelling a project in sequential phases}} {{EngvarB|date=January 2023}} {{Update|date=October 2021}} जलप्रपात मॉडल परियो...")
 
No edit summary
Line 2: Line 2:
{{EngvarB|date=January 2023}}
{{EngvarB|date=January 2023}}
{{Update|date=October 2021}}
{{Update|date=October 2021}}
जलप्रपात मॉडल परियोजना गतिविधियों का रैखिक [[अनुक्रम]] चरणों में टूटना है, जिसका अर्थ है कि वे एक दूसरे पर पारित हो जाते हैं, जहां प्रत्येक चरण पिछले एक के डिलिवरेबल्स पर निर्भर करता है और कार्यों की विशेषज्ञता से मेल खाता है।<ref name=":0" />  [[इंजीनियरिंग डिजाइन]] के कुछ क्षेत्रों के लिए दृष्टिकोण विशिष्ट है। [[सॉफ्टवेयर विकास प्रक्रिया]] में,<ref name=":0">{{Cite journal|last1=Petersen|first1=Kai|last2=Wohlin|first2=Claes|last3=Baca|first3=Dejan|date=2009|editor-last=Bomarius|editor-first=Frank|editor2-last=Oivo|editor2-first=Markku|editor3-last=Jaring|editor3-first=Päivi|editor4-last=Abrahamsson|editor4-first=Pekka|title=The Waterfall Model in Large-Scale Development|url=https://link.springer.com/chapter/10.1007/978-3-642-02152-7_29|journal=Product-Focused Software Process Improvement|series=Lecture Notes in Business Information Processing|volume=32 |language=en|location=Berlin, Heidelberg|publisher=Springer|pages=386–400|doi=10.1007/978-3-642-02152-7_29|isbn=978-3-642-02152-7}}</ref> यह कम पुनरावृत्त और लचीले दृष्टिकोणों में से एक है, क्योंकि अवधारणा, दीक्षा, [[विश्लेषण]], [[सॉफ्टवेर डिज़ाइन]], [[सॉफ्टवेयर निर्माण]], सॉफ्टवेयर परीक्षण, [[कार्यान्वयन]] और सॉफ्टवेयर रखरखाव के चरणों के माध्यम से प्रगति काफी हद तक एक दिशा (एक झरने की तरह नीचे की ओर) में बहती है।<ref>{{Cite web|title=The Traditional Waterfall Approach|url=https://www.umsl.edu/~hugheyd/is6840/waterfall.html|access-date=2022-02-23|website=www.umsl.edu}}</ref>{{better source needed|date=January 2023|reason=The page referenced is a personal page from a university website with a big disclaimer at the bottom that it's not endorsed by the university.}} जलप्रपात मॉडल प्रारंभिक [[सिस्टम विकास जीवन चक्र]] दृष्टिकोण है जिसका उपयोग सॉफ्टवेयर विकास में किया गया था।{{Citation needed|date=January 2023|reason=That's a very specific claim. Needs a reference.}}
जलप्रपात मॉडल परियोजना गतिविधियों का रैखिक [[अनुक्रम]] चरणों में टूटना है, जिसका अर्थ है कि वे एक दूसरे पर पारित हो जाते हैं, जहां प्रत्येक चरण पिछले एक के डिलिवरेबल्स पर निर्भर करता है और कार्यों की विशेषज्ञता से मेल खाता है।<ref name=":0" />  [[इंजीनियरिंग डिजाइन]] के कुछ क्षेत्रों के लिए दृष्टिकोण विशिष्ट है। [[सॉफ्टवेयर विकास प्रक्रिया]] में,<ref name=":0">{{Cite journal|last1=Petersen|first1=Kai|last2=Wohlin|first2=Claes|last3=Baca|first3=Dejan|date=2009|editor-last=Bomarius|editor-first=Frank|editor2-last=Oivo|editor2-first=Markku|editor3-last=Jaring|editor3-first=Päivi|editor4-last=Abrahamsson|editor4-first=Pekka|title=The Waterfall Model in Large-Scale Development|url=https://link.springer.com/chapter/10.1007/978-3-642-02152-7_29|journal=Product-Focused Software Process Improvement|series=Lecture Notes in Business Information Processing|volume=32 |language=en|location=Berlin, Heidelberg|publisher=Springer|pages=386–400|doi=10.1007/978-3-642-02152-7_29|isbn=978-3-642-02152-7}}</ref> यह कम पुनरावृत्त और लचीले दृष्टिकोणों में से एक है, क्योंकि अवधारणा, दीक्षा, [[विश्लेषण]], [[सॉफ्टवेर डिज़ाइन]], [[सॉफ्टवेयर निर्माण]], सॉफ्टवेयर परीक्षण, [[कार्यान्वयन]] और सॉफ्टवेयर रखरखाव के चरणों के माध्यम से प्रगति अधिक सीमा तक एक दिशा (एक झरने की तरह नीचे की ओर) में बहती है।<ref>{{Cite web|title=The Traditional Waterfall Approach|url=https://www.umsl.edu/~hugheyd/is6840/waterfall.html|access-date=2022-02-23|website=www.umsl.edu}}</ref>{{better source needed|date=January 2023|reason=The page referenced is a personal page from a university website with a big disclaimer at the bottom that it's not endorsed by the university.}} जलप्रपात मॉडल प्रारंभिक [[सिस्टम विकास जीवन चक्र|प्रणाली विकास जीवन चक्र]] दृष्टिकोण है जिसका उपयोग सॉफ्टवेयर विकास में किया गया था।{{Citation needed|date=January 2023|reason=That's a very specific claim. Needs a reference.}}
जलप्रपात विकास मॉडल की उत्पत्ति वि[[निर्माण]] और निर्माण उद्योगों में हुई,{{Citation needed|date=October 2021|reason=A link that it DID originate in these industries is needed}} जहां अत्यधिक संरचित भौतिक वातावरण का मतलब था कि विकास प्रक्रिया में डिजाइन परिवर्तन निषेधात्मक रूप से महंगे हो गए थे। {{Citation needed|date=February 2021|reason=prohibitive is a vague and value-laden word and the claim may not be true at all}} जब पहली बार सॉफ्टवेयर विकास के लिए अपनाया गया था, ज्ञान आधारित रचनात्मक कार्य के लिए कोई मान्यता प्राप्त विकल्प नहीं था।<ref name="benington">{{cite journal |last=Benington |first=Herbert D. |title=Production of Large Computer Programs |journal=IEEE Annals of the History of Computing |date=1 October 1983 |volume=5 |issue=4 |pages=350–361 |doi=10.1109/MAHC.1983.10102 |publisher=IEEE Educational Activities Department |s2cid=8632276 |url=http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |access-date=2011-03-21}} {{webarchive |url=https://web.archive.org/web/20110718084251/http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |date=July 18, 2011 }}</ref>{{better source needed|date=March 2021|reason=the referenced article neither uses the term waterfall nor describes that there was only one recognized way of developing software}}
जलप्रपात विकास मॉडल की उत्पत्ति वि[[निर्माण]] और निर्माण उद्योगों में हुई,{{Citation needed|date=October 2021|reason=A link that it DID originate in these industries is needed}} जहां अत्यधिक संरचित भौतिक वातावरण का कारणथा कि विकास प्रक्रिया में डिजाइन परिवर्तन निषेधात्मक रूप से महंगे हो गए थे। {{Citation needed|date=February 2021|reason=prohibitive is a vague and value-laden word and the claim may not be true at all}} जब पहली बार सॉफ्टवेयर विकास के लिए अपनाया गया था, ज्ञान आधारित रचनात्मक कार्य के लिए कोई मान्यता प्राप्त विकल्प नहीं था।<ref name="benington">{{cite journal |last=Benington |first=Herbert D. |title=Production of Large Computer Programs |journal=IEEE Annals of the History of Computing |date=1 October 1983 |volume=5 |issue=4 |pages=350–361 |doi=10.1109/MAHC.1983.10102 |publisher=IEEE Educational Activities Department |s2cid=8632276 |url=http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |access-date=2011-03-21}} {{webarchive |url=https://web.archive.org/web/20110718084251/http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |date=July 18, 2011 }}</ref>{{better source needed|date=March 2021|reason=the referenced article neither uses the term waterfall nor describes that there was only one recognized way of developing software}}




== इतिहास ==
== इतिहास ==
सॉफ्टवेयर इंजीनियरिंग में ऐसे चरणों के उपयोग का वर्णन करने वाली पहली ज्ञात प्रस्तुति 29 जून 1956 को डिजिटल कंप्यूटर के लिए उन्नत प्रोग्रामिंग विधियों पर संगोष्ठी में [[फेलिक्स लोरेंजो टोरेस]] और हर्बर्ट डी. बेनिंगटन द्वारा आयोजित की गई थी।{{Citation needed|date=February 2021|reason=A link to the supposed first presentation of something does not show that it WAS the first presentation of something. Plus, a Google Books search of that paper returns no hits for the word waterfall. The full document is not available online.}}.<ref>{{Citation |publisher=Office of Naval Research, Dept. of the Navy |location=[Washington, D.C.] |title=Symposium on advanced programming methods for digital computers |author=United States, Navy Mathematical Computing Advisory Panel |date=29 June 1956 |oclc=10794738 }}</ref> यह प्रस्तुति [[अर्ध स्वचालित ग्राउंड पर्यावरण]] के लिए सॉफ्टवेयर के विकास के बारे में थी। 1983 में पेपर को बेनिंगटन द्वारा एक प्राक्कथन के साथ पुनर्प्रकाशित किया गया था जिसमें बताया गया था कि चरणों को कार्यों की विशेषज्ञता के अनुसार आयोजित किया गया था, और यह इंगित करते हुए कि प्रक्रिया वास्तव में एक सख्त टॉप-डाउन फैशन में नहीं की गई थी, लेकिन एक प्रोटोटाइप पर निर्भर थी। .<ref name="benington" />
सॉफ्टवेयर इंजीनियरिंग में ऐसे चरणों के उपयोग का वर्णन करने वाली पहली ज्ञात प्रस्तुति 29 जून 1956 को डिजिटल कंप्यूटर के लिए उन्नत प्रोग्रामिंग विधियों पर संगोष्ठी में [[फेलिक्स लोरेंजो टोरेस]] और हर्बर्ट डी. बेनिंगटन द्वारा आयोजित की गई थी।{{Citation needed|date=February 2021|reason=A link to the supposed first presentation of something does not show that it WAS the first presentation of something. Plus, a Google Books search of that paper returns no hits for the word waterfall. The full document is not available online.}}.<ref>{{Citation |publisher=Office of Naval Research, Dept. of the Navy |location=[Washington, D.C.] |title=Symposium on advanced programming methods for digital computers |author=United States, Navy Mathematical Computing Advisory Panel |date=29 June 1956 |oclc=10794738 }}</ref> यह प्रस्तुति [[अर्ध स्वचालित ग्राउंड पर्यावरण]] के लिए सॉफ्टवेयर के विकास के बारे में थी। 1983 में पेपर को बेनिंगटन द्वारा एक प्राक्कथन के साथ पुनर्प्रकाशित किया गया था जिसमें बताया गया था कि चरणों को कार्यों की विशेषज्ञता के अनुसार आयोजित किया गया था, और यह इंगित करते हुए कि प्रक्रिया वास्तव में एक सख्त टॉप-डाउन फैशन में नहीं की गई थी, किन्तुएक प्रोटोटाइप पर निर्भर थी। .<ref name="benington" />


हालांकि पेपर में वॉटरफॉल शब्द का इस्तेमाल नहीं किया गया है, लेकिन प्रक्रिया का पहला औपचारिक विस्तृत आरेख बाद में वॉटरफॉल मॉडल के रूप में जाना जाता है{{Citation needed|date=October 2021|reason=often? Where, by who?}} विंस्टन डब्ल्यू रॉयस द्वारा 1970 के एक लेख के रूप में उद्धृत।<ref name="royce">{{Citation |surname=Royce |given=Winston |title=Managing the Development of Large Software Systems |journal=Proceedings of IEEE WESCON |volume=26 |issue=August | year=1970 | pages=1–9 |url=http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf }}</ref><ref>{{ cite web | url=http://www.informatik.uni-bremen.de/uniform/vm97/def/def_w/WATERFALL.htm | title=Waterfall | website=Bremen University - Mathematics and Computer Science }}</ref><ref>{{Cite journal|last1=Abbas|first1=Noura|last2=Gravell|first2=Andrew M.|last3=Wills|first3=Gary B.|date=2008|editor-last=Abrahamsson|editor-first=Pekka|editor2-last=Baskerville|editor2-first=Richard|editor3-last=Conboy|editor3-first=Kieran|editor4-last=Fitzgerald|editor4-first=Brian|editor5-last=Morgan|editor5-first=Lorraine|editor6-last=Wang|editor6-first=Xiaofeng|title=Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From?|url=https://link.springer.com/chapter/10.1007/978-3-540-68255-4_10|journal=Agile Processes in Software Engineering and Extreme Programming|series=Lecture Notes in Business Information Processing|volume=9 |language=en|location=Berlin, Heidelberg|publisher=Springer|pages=94–103|doi=10.1007/978-3-540-68255-4_10|isbn=978-3-540-68255-4}}</ref> हालांकि उन्होंने यह भी महसूस किया कि इस तथ्य से उपजी बड़ी खामियां थीं कि परीक्षण केवल प्रक्रिया के अंत में हुआ, जिसे उन्होंने जोखिम भरा बताया और विफलता को आमंत्रित किया।<ref name="royce" />उनके पेपर के बाकी हिस्सों ने पांच चरणों की शुरुआत की जो उन्होंने महसूस किया कि अनछुए जलप्रपात दृष्टिकोण से जुड़े अधिकांश विकास जोखिमों को खत्म करने के लिए आवश्यक थे।<ref name="royce" />
चूंकि पेपर में वॉटरफॉल शब्द का उपयोग नहीं किया गया है, किन्तुप्रक्रिया का पहला औपचारिक विस्तृत आरेख बाद में वॉटरफॉल मॉडल के रूप में जाना जाता है{{Citation needed|date=October 2021|reason=often? Where, by who?}} विंस्टन डब्ल्यू रॉयस द्वारा 1970 के एक लेख के रूप में उद्धृत।<ref name="royce">{{Citation |surname=Royce |given=Winston |title=Managing the Development of Large Software Systems |journal=Proceedings of IEEE WESCON |volume=26 |issue=August | year=1970 | pages=1–9 |url=http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf }}</ref><ref>{{ cite web | url=http://www.informatik.uni-bremen.de/uniform/vm97/def/def_w/WATERFALL.htm | title=Waterfall | website=Bremen University - Mathematics and Computer Science }}</ref><ref>{{Cite journal|last1=Abbas|first1=Noura|last2=Gravell|first2=Andrew M.|last3=Wills|first3=Gary B.|date=2008|editor-last=Abrahamsson|editor-first=Pekka|editor2-last=Baskerville|editor2-first=Richard|editor3-last=Conboy|editor3-first=Kieran|editor4-last=Fitzgerald|editor4-first=Brian|editor5-last=Morgan|editor5-first=Lorraine|editor6-last=Wang|editor6-first=Xiaofeng|title=Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From?|url=https://link.springer.com/chapter/10.1007/978-3-540-68255-4_10|journal=Agile Processes in Software Engineering and Extreme Programming|series=Lecture Notes in Business Information Processing|volume=9 |language=en|location=Berlin, Heidelberg|publisher=Springer|pages=94–103|doi=10.1007/978-3-540-68255-4_10|isbn=978-3-540-68255-4}}</ref> चूंकि उन्होंने यह भी अनुभूत किया कि इस तथ्य से उपजी बड़ी खामियां थीं कि परीक्षण केवल प्रक्रिया के अंत में हुआ, जिसे उन्होंने कठिन परिस्थिति भरा बताया और विफलता को आमंत्रित किया।<ref name="royce" />उनके पेपर के बाकी हिस्सों ने पांच चरणों की प्रारंभिक की जो उन्होंने अनुभूत किया कि अनछुए जलप्रपात दृष्टिकोण से जुड़े अधिकांश विकास कठिन परिस्थितिों को खत्म करने के लिए आवश्यक थे।<ref name="royce" />


रॉयस के पांच अतिरिक्त चरणों (जिसमें विकास के विभिन्न चरणों में पूर्ण प्रलेखन लिखना शामिल था) ने कभी भी मुख्यधारा की पकड़ नहीं बनाई, लेकिन जलप्रपात के दृष्टिकोण का वर्णन करते समय उन्होंने जिसे एक त्रुटिपूर्ण प्रक्रिया माना उसका आरेख प्रारंभिक बिंदु बन गया।<ref>Conrad Weisert, [http://www.idinews.com/waterfall.html Waterfall methodology: there's no such thing!]</ref>{{better source needed|date=March 2021|reason=the reference never says it was a commonly used software development practice or anything like that.}}
रॉयस के पांच अतिरिक्त चरणों (जिसमें विकास के विभिन्न चरणों में पूर्ण प्रलेखन लिखना सम्मिलित  था) ने कभी भी मुख्यधारा की पकड़ नहीं बनाई, किन्तुजलप्रपात के दृष्टिकोण का वर्णन करते समय उन्होंने जिसे एक त्रुटिपूर्ण प्रक्रिया माना उसका आरेख प्रारंभिक बिंदु बन गया।<ref>Conrad Weisert, [http://www.idinews.com/waterfall.html Waterfall methodology: there's no such thing!]</ref>{{better source needed|date=March 2021|reason=the reference never says it was a commonly used software development practice or anything like that.}}
जलप्रपात शब्द का सबसे पहला प्रयोग बेल और थायर द्वारा 1976 के पेपर में किया गया हो सकता है।<ref>Bell, Thomas E., and T. A. Thayer. [http://pdf.aminer.org/000/361/405/software_requirements_are_they_really_a_problem.pdf Software requirements: Are they really a problem?] ''Proceedings of the 2nd international conference on Software engineering.'' IEEE Computer Society Press, 1976.</ref>{{better source needed|date=March 2021|reason=may have been? The use of a term in a paper doesn't mean it was the first use of the term.}}
जलप्रपात शब्द का सबसे पहला प्रयोग बेल और थायर द्वारा 1976 के पेपर में किया गया हो सकता है।<ref>Bell, Thomas E., and T. A. Thayer. [http://pdf.aminer.org/000/361/405/software_requirements_are_they_really_a_problem.pdf Software requirements: Are they really a problem?] ''Proceedings of the 2nd international conference on Software engineering.'' IEEE Computer Society Press, 1976.</ref>{{better source needed|date=March 2021|reason=may have been? The use of a term in a paper doesn't mean it was the first use of the term.}}
1985 में, संयुक्त राज्य अमेरिका के रक्षा विभाग ने [[DOD-STD-2167A]] में इस दृष्टिकोण पर कब्जा कर लिया{{Citation needed|date=February 2021|reason=the process shown in the standard bears no relation to the classic waterfall approach}}सॉफ्टवेयर विकास ठेकेदारों के साथ काम करने के लिए उनके मानक, जिसमें कहा गया है कि ठेकेदार एक सॉफ्टवेयर विकास चक्र लागू करेगा जिसमें निम्नलिखित छह चरण शामिल हैं: सॉफ्टवेयर आवश्यकता विश्लेषण, प्रारंभिक डिजाइन, विस्तृत डिजाइन, कोडिंग और यूनिट परीक्षण, एकीकरण और परीक्षण।<ref>{{Cite web|url=http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf|title=Military Standard Defense System Software Development}}</ref>
1985 में, संयुक्त राज्य अमेरिका के रक्षा विभाग ने [[DOD-STD-2167A]] में इस दृष्टिकोण पर कब्जा कर लिया सॉफ्टवेयर विकास ठेकेदारों के साथ काम करने के लिए उनके मानक, जिसमें कहा गया है कि ठेकेदार एक सॉफ्टवेयर विकास चक्र प्रयुक्त करेगा जिसमें निम्नलिखित छह चरण सम्मिलित  हैं: सॉफ्टवेयर आवश्यकता विश्लेषण, प्रारंभिक डिजाइन, विस्तृत डिजाइन, कोडिंग और यूनिट परीक्षण, एकीकरण और परीक्षण।<ref>{{Cite web|url=http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf|title=Military Standard Defense System Software Development}}</ref>




== मॉडल ==
== मॉडल ==
रॉयस के मूल जलप्रपात मॉडल में{{Citation needed|date=February 2021|reason=Royce did not describe the model mentioned here}}क्रम में निम्नलिखित चरणों का पालन किया जाता है:
रॉयस के मूल जलप्रपात मॉडल में{{Citation needed|date=February 2021|reason=Royce did not describe the model mentioned here}}क्रम में निम्नलिखित चरणों का पालन किया जाता है:
# सिस्टम आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताएँ: उत्पाद आवश्यकताएँ दस्तावेज़ में कैप्चर की गई हैं
# प्रणाली आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताएँ: उत्पाद आवश्यकताएँ दस्तावेज़ में कैप्चर की गई हैं
# आवश्यकता विश्लेषण: जिसके परिणामस्वरूप मॉडल-संचालित सॉफ़्टवेयर विकास, [[डेटाबेस स्कीमा]] और व्यावसायिक नियम होते हैं
# आवश्यकता विश्लेषण: जिसके परिणामस्वरूप मॉडल-संचालित सॉफ़्टवेयर विकास, [[डेटाबेस स्कीमा]] और व्यावसायिक नियम होते हैं
# सॉफ्टवेयर डिजाइन: [[सॉफ़्टवेयर वास्तुशिल्प]] के परिणामस्वरूप
# सॉफ्टवेयर डिजाइन: [[सॉफ़्टवेयर वास्तुशिल्प]] के परिणामस्वरूप
# [[कंप्यूटर प्रोग्रामिंग]][[मॉडल-संचालित सॉफ्टवेयर विकास]], [[इकाई का परीक्षण]] और सॉफ्टवेयर का [[प्रणाली एकीकरण]]
# [[कंप्यूटर प्रोग्रामिंग]][[मॉडल-संचालित सॉफ्टवेयर विकास]], [[इकाई का परीक्षण]] और सॉफ्टवेयर का [[प्रणाली एकीकरण]]
# सॉफ्टवेयर परीक्षण: [[सॉफ्टवेयर बग]] की व्यवस्थित खोज और [[डिबगिंग]]
# सॉफ्टवेयर परीक्षण: [[सॉफ्टवेयर बग]] की व्यवस्थित खोज और [[डिबगिंग]]
# [[कंप्यूटर ऑपरेटर]]: इंस्टालेशन (कंप्यूटर प्रोग्राम), [[आंकड़ों का विस्थापन]], तकनीकी सहायता और संपूर्ण सिस्टम का सॉफ्टवेयर रखरखाव
# [[कंप्यूटर ऑपरेटर]]: इंस्टालेशन (कंप्यूटर प्रोग्राम), [[आंकड़ों का विस्थापन]], विधि ी सहायता और संपूर्ण प्रणाली का सॉफ्टवेयर रखरखाव


इस प्रकार जलप्रपात मॉडल का कहना है कि किसी को एक चरण में तभी जाना चाहिए जब उसके पिछले चरण की समीक्षा और सत्यापन किया जाए।
इस प्रकार जलप्रपात मॉडल का कहना है कि किसी को एक चरण में तभी जाना चाहिए जब उसके पिछले चरण की समीक्षा और सत्यापन किया जाए।


विभिन्न संशोधित जलप्रपात मॉडल (रॉयस के अंतिम मॉडल सहित), हालांकि, इस प्रक्रिया में मामूली या बड़े बदलाव शामिल हो सकते हैं।<ref name="royce" />इन विविधताओं में डाउनस्ट्रीम में खामियां पाए जाने के बाद पिछले चक्र में वापस आना, या डाउनस्ट्रीम चरणों को अपर्याप्त समझे जाने पर डिजाइन चरण में वापस आना शामिल था।
विभिन्न संशोधित जलप्रपात मॉडल (रॉयस के अंतिम मॉडल सहित), चूंकि, इस प्रक्रिया में सामान्य या बड़े बदलाव सम्मिलित  हो सकते हैं।<ref name="royce" />इन विविधताओं में डाउनस्ट्रीम में खामियां पाए जाने के बाद पिछले चक्र में वापस आना, या डाउनस्ट्रीम चरणों को अपर्याप्त समझे जाने पर डिजाइन चरण में वापस आना सम्मिलित  था।


== सहायक तर्क ==
== सहायक तर्क ==
सॉफ्टवेयर उत्पादन चक्र में शुरुआती समय व्यतीत करने से बाद के चरणों में लागत कम हो सकती है। उदाहरण के लिए, शुरुआती चरणों में पाई गई समस्या (जैसे आवश्यकताएं विनिर्देश) प्रक्रिया में बाद में पाए गए उसी बग की तुलना में ठीक करने के लिए सस्ता है (50 से 200 के कारक द्वारा)।<ref name="rapid">{{cite book |last=McConnell |first=Steve |title=Rapid Development: Taming Wild Software Schedules |publisher=Microsoft Press |year=1996 |isbn=1-55615-900-5 |url=https://archive.org/details/rapiddevelopment00mcco }}</ref>
सॉफ्टवेयर उत्पादन चक्र में प्रारंभिक  समय व्यतीत करने से बाद के चरणों में निवेश कम हो सकती है। उदाहरण के लिए, प्रारंभिक  चरणों में पाई गई समस्या (जैसे आवश्यकताएं विनिर्देश) प्रक्रिया में बाद में पाए गए उसी बग की तुलना में ठीक करने के लिए सस्ता है (50 से 200 के कारक द्वारा)।<ref name="rapid">{{cite book |last=McConnell |first=Steve |title=Rapid Development: Taming Wild Software Schedules |publisher=Microsoft Press |year=1996 |isbn=1-55615-900-5 |url=https://archive.org/details/rapiddevelopment00mcco }}</ref>
सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 20-40% समय, कोडिंग के लिए 30-40% समय, और शेष परीक्षण और कार्यान्वयन के लिए समर्पित समय के साथ एक परियोजना अनुसूची होती है। वास्तविक परियोजना संगठन को अत्यधिक संरचित होने की आवश्यकता है। अधिकांश मध्यम और बड़ी परियोजनाओं में प्रक्रियाओं और नियंत्रणों का एक विस्तृत सेट शामिल होगा, जो परियोजना की प्रत्येक प्रक्रिया को विनियमित करते हैं।<ref>{{ cite web |title=Waterfall Software Development Model |url=http://www.oxagile.com/company/blog/the-waterfall-model/ |access-date=11 August 2014 |date=5 February 2014 }}</ref>{{failed verification|date=March 2021}}
सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 20-40% समय, कोडिंग के लिए 30-40% समय, और शेष परीक्षण और कार्यान्वयन के लिए समर्पित समय के साथ एक परियोजना अनुसूची होती है। वास्तविक परियोजना संगठन को अत्यधिक संरचित होने की आवश्यकता है। अधिकांश मध्यम और बड़ी परियोजनाओं में प्रक्रियाओं और नियंत्रणों का एक विस्तृत सेट सम्मिलित  होगा, जो परियोजना की प्रत्येक प्रक्रिया को विनियमित करते हैं।<ref>{{ cite web |title=Waterfall Software Development Model |url=http://www.oxagile.com/company/blog/the-waterfall-model/ |access-date=11 August 2014 |date=5 February 2014 }}</ref>{{failed verification|date=March 2021}}
जलप्रपात मॉडल के लिए एक और तर्क यह है कि यह दस्तावेज़ीकरण (जैसे आवश्यकता दस्तावेज़ और डिज़ाइन दस्तावेज़) के साथ-साथ स्रोत कोड पर ज़ोर देता है।{{Citation needed|date=March 2021|reason=Who argues this?}} कम अच्छी तरह से डिजाइन और प्रलेखित कार्यप्रणाली में, यदि टीम के सदस्य परियोजना पूरी होने से पहले चले जाते हैं, तो ज्ञान खो जाता है, और परियोजना के लिए नुकसान से उबरना मुश्किल हो सकता है। यदि पूरी तरह से काम करने वाला डिज़ाइन दस्तावेज़ मौजूद है (जैसा कि [[बड़ा डिज़ाइन अप फ्रंट]] और वॉटरफॉल मॉडल का इरादा है), नए टीम के सदस्य या पूरी तरह से नई टीम भी दस्तावेज़ों को पढ़कर खुद को परिचित करने में सक्षम होनी चाहिए।<ref>{{ cite news |author=Arcisphere technologies |title=Tutorial: The Software Development Life Cycle (SDLC) |url=http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-LifeCycle-SDLC.pdf |year=2012 |access-date=2012-11-13 }}</ref>
जलप्रपात मॉडल के लिए एक और तर्क यह है कि यह दस्तावेज़ीकरण (जैसे आवश्यकता दस्तावेज़ और डिज़ाइन दस्तावेज़) के साथ-साथ स्रोत कोड पर ज़ोर देता है।{{Citation needed|date=March 2021|reason=Who argues this?}} कम अच्छी तरह से डिजाइन और प्रलेखित कार्यप्रणाली में, यदि टीम के सदस्य परियोजना पूरी होने से पहले चले जाते हैं, तो ज्ञान खो जाता है, और परियोजना के लिए हानि से उबरना जटिल हो सकता है। यदि पूरी तरह से काम करने वाला डिज़ाइन दस्तावेज़ उपस्थितहै (जैसा कि [[बड़ा डिज़ाइन अप फ्रंट]] और वॉटरफॉल मॉडल का इरादा है), नए टीम के सदस्य या पूरी तरह से नई टीम भी दस्तावेज़ों को पढ़कर खुद को परिचित करने में सक्षम होनी चाहिए।<ref>{{ cite news |author=Arcisphere technologies |title=Tutorial: The Software Development Life Cycle (SDLC) |url=http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-LifeCycle-SDLC.pdf |year=2012 |access-date=2012-11-13 }}</ref>
जलप्रपात मॉडल एक संरचित दृष्टिकोण प्रदान करता है; मॉडल स्वयं असतत, आसानी से समझने योग्य और व्याख्या करने योग्य चरणों के माध्यम से रैखिक रूप से आगे बढ़ता है और इस प्रकार समझना आसान होता है; यह विकास प्रक्रिया में आसानी से पहचाने जाने योग्य मील के पत्थर भी प्रदान करता है। शायद यही कारण है कि जलप्रपात मॉडल का उपयोग कई सॉफ्टवेयर इंजीनियरिंग ग्रंथों और पाठ्यक्रमों में विकास मॉडल के शुरुआती उदाहरण के रूप में किया जाता है।<ref>{{ cite web |last=Hughey |first=Douglas |title=Comparing Traditional Systems Analysis and Design with Agile Methodologies |url=http://www.umsl.edu/~hugheyd/is6840/waterfall.html |publisher=University of Missouri – St. Louis |access-date=11 August 2014 |date=2009}}</ref>
 
जलप्रपात मॉडल एक संरचित दृष्टिकोण प्रदान करता है; मॉडल स्वयं असतत, आसानी से समझने योग्य और व्याख्या करने योग्य चरणों के माध्यम से रैखिक रूप से आगे बढ़ता है और इस प्रकार समझना आसान होता है; यह विकास प्रक्रिया में आसानी से पहचाने जाने योग्य मील के पत्थर भी प्रदान करता है। संभवतः यही कारण है कि जलप्रपात मॉडल का उपयोग कई सॉफ्टवेयर इंजीनियरिंग ग्रंथों और पाठ्यक्रमों में विकास मॉडल के प्रारंभिक  उदाहरण के रूप में किया जाता है।<ref>{{cite web |last=Hughey |first=Douglas |title=Comparing Traditional Systems Analysis and Design with Agile Methodologies |url=http://www.umsl.edu/~hugheyd/is6840/waterfall.html |publisher=University of Missouri – St. Louis |access-date=11 August 2014 |date=2009}}</ref>
 




== आलोचना ==
== आलोचना ==
काम करने वाले सॉफ़्टवेयर को देखने से पहले क्लाइंट ठीक से नहीं जान सकते हैं कि उनकी ज़रूरतें क्या हैं और इसलिए अपनी ज़रूरतों को बदलें, जिससे रीडिज़ाइन, पुनर्विकास और पुनर्परीक्षण और बढ़ी हुई लागत हो सकती है।<ref>{{cite journal |last1=Parnas |first1=David L. |last2=Clements |first2=Paul C. |title=A rational design process: How and why to fake it |journal=IEEE Transactions on Software Engineering|date=1986 |issue=2 |pages=251–257 |doi=10.1109/TSE.1986.6312940 |s2cid=5838439 |url=https://www.cs.tufts.edu/~nr/cs257/archive/david-parnas/fake-it.pdf |access-date=2011-03-21}}</ref>
काम करने वाले सॉफ़्टवेयर को देखने से पहले क्लाइंट ठीक से नहीं जान सकते हैं कि उनकी ज़रूरतें क्या हैं और इसलिए अपनी ज़रूरतों को बदलें, जिससे रीडिज़ाइन, पुनर्विकास और पुनर्परीक्षण और बढ़ी हुई निवेश हो सकती है।<ref>{{cite journal |last1=Parnas |first1=David L. |last2=Clements |first2=Paul C. |title=A rational design process: How and why to fake it |journal=IEEE Transactions on Software Engineering|date=1986 |issue=2 |pages=251–257 |doi=10.1109/TSE.1986.6312940 |s2cid=5838439 |url=https://www.cs.tufts.edu/~nr/cs257/archive/david-parnas/fake-it.pdf |access-date=2011-03-21}}</ref>
नए सॉफ़्टवेयर उत्पाद या फीचर को डिज़ाइन करते समय डिज़ाइनर भविष्य की कठिनाइयों से अवगत नहीं हो सकते हैं, इस मामले में डिज़ाइन को संशोधित करना बेहतर होता है, जो किसी नए खोजी गई बाधाओं, आवश्यकताओं या समस्याओं के लिए जिम्मेदार नहीं होता है।<ref>{{cite book |last=McConnell |first=Steve |title=Code Complete, 2nd edition |publisher=Microsoft Press |year=2004 |isbn=1-55615-484-4 |url=https://archive.org/details/codecompleteprac00mcco }}</ref>
नए सॉफ़्टवेयर उत्पाद या फीचर को डिज़ाइन करते समय डिज़ाइनर भविष्य की कठिनाइयों से अवगत नहीं हो सकते हैं, इस मामले में डिज़ाइन को संशोधित करना उत्तम होता है, जो किसी नए खोजी गई बाधाओं, आवश्यकताओं या समस्याओं के लिए जिम्मेदार नहीं होता है।<ref>{{cite book |last=McConnell |first=Steve |title=Code Complete, 2nd edition |publisher=Microsoft Press |year=2004 |isbn=1-55615-484-4 |url=https://archive.org/details/codecompleteprac00mcco }}</ref>  
संगठन मौजूदा मैनुअल सिस्टम की जांच करने और विश्लेषण करने के लिए कि वे क्या करते हैं और उन्हें कैसे बदला जा सकता है, सिस्टम विश्लेषकों को नियोजित करके ग्राहकों से ठोस आवश्यकताओं की कमी से निपटने का प्रयास कर सकते हैं। हालांकि, व्यवहार में, [[सिस्टम विश्लेषण]] और प्रोग्रामिंग के बीच सख्त अलगाव को बनाए रखना मुश्किल है।<ref>{{cite book|last=Ensmenger|first=Nathan|year=2010|title=The Computer Boys Take Over|url=https://archive.org/details/computerboystake00ensm|url-access=limited|isbn=978-0-262-05093-7|page=[https://archive.org/details/computerboystake00ensm/page/n50 42]}}</ref> ऐसा इसलिए है क्योंकि किसी भी गैर-तुच्छ प्रणाली को लागू करने से लगभग अनिवार्य रूप से उन मुद्दों और बढ़त के मामलों का खुलासा होगा, जिन पर सिस्टम विश्लेषक विचार नहीं करते थे।


शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के जवाब में, संशोधित जलप्रपात मॉडल पेश किए गए, जैसे कि साशिमी (अतिव्यापी चरणों के साथ जलप्रपात), उपपरियोजनाओं के साथ जलप्रपात, और जोखिम में कमी के साथ जलप्रपात।<ref name="rapid" />
संगठन आधुनिक  मैनुअल प्रणाली की जांच करने और विश्लेषण करने के लिए कि वे क्या करते हैं और उन्हें कैसे बदला जा सकता है, प्रणाली विश्लेषकों को नियोजित करके ग्राहकों से ठोस आवश्यकताओं की कमी से निपटने का प्रयास कर सकते हैं। चूंकि, व्यवहार में, [[सिस्टम विश्लेषण|प्रणाली विश्लेषण]] और प्रोग्रामिंग के बीच सख्त अलगाव को बनाए रखना  जटिल है।<ref>{{cite book|last=Ensmenger|first=Nathan|year=2010|title=The Computer Boys Take Over|url=https://archive.org/details/computerboystake00ensm|url-access=limited|isbn=978-0-262-05093-7|page=[https://archive.org/details/computerboystake00ensm/page/n50 42]}}</ref> ऐसा इसलिए है क्योंकि किसी भी गैर-तुच्छ प्रणाली को प्रयुक्त करने से लगभग अनिवार्य रूप से उन उद्देश्य  और बढ़त के स्थितियों का खुलासा होगा, जिन पर प्रणाली विश्लेषक विचार नहीं करते थे।
 
शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के उत्तर में, संशोधित जलप्रपात मॉडल पेश किए गए, जैसे कि साशिमी (अतिव्यापी चरणों के साथ जलप्रपात), उपपरियोजनाओं के साथ जलप्रपात, और कठिन परिस्थिति में कमी के साथ जलप्रपात।<ref name="rapid" />
 
संयुक्त राज्य अमेरिका के रक्षा विभाग जैसे कुछ संगठनों ने अब जलप्रपात-प्रकार की पद्धतियों के खिलाफ एक घोषित वरीयता दी है, जो 1994 में जारी [[MIL-STD-498]] से प्रारंभ  हुई, जो विकासवादी अधिग्रहण और [[पुनरावृत्त और वृद्धिशील विकास]] को प्रोत्साहित करती है।<ref>{{cite journal |last1=Larman |first1=Craig |last2=Basili |first2=Victir |title=Iterative and Incremental Development: A Brief History |journal=IEEE Computer |year=2003 |edition=June |url=http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375 |doi=10.1109/MC.2003.1204375 |volume=36 |issue=6 |pages=47–56|s2cid=9240477 }}</ref>


संयुक्त राज्य अमेरिका के रक्षा विभाग जैसे कुछ संगठनों ने अब जलप्रपात-प्रकार की पद्धतियों के खिलाफ एक घोषित वरीयता दी है, जो 1994 में जारी [[MIL-STD-498]] से शुरू हुई, जो विकासवादी अधिग्रहण और [[पुनरावृत्त और वृद्धिशील विकास]] को प्रोत्साहित करती है।<ref>{{cite journal |last1=Larman |first1=Craig |last2=Basili |first2=Victir |title=Iterative and Incremental Development: A Brief History |journal=IEEE Computer |year=2003 |edition=June |url=http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375 |doi=10.1109/MC.2003.1204375 |volume=36 |issue=6 |pages=47–56|s2cid=9240477 }}</ref>
फुर्तीले सॉफ्टवेयर विकास के पैरोकार तर्क देते हैं कि वॉटरफॉल मॉडल सॉफ्टवेयर विकसित करने के लिए एक अप्रभावी प्रक्रिया है, कुछ संशयवादी सुझाव देते हैं कि वॉटरफॉल मॉडल एक गलत तर्क है जिसका उपयोग विशुद्ध रूप से वैकल्पिक विकास पद्धतियों को बाजार में करने के लिए किया जाता है।<ref>[http://get.syr.edu/news_alt.aspx?recid=401 A Waterfall Systems Development Methodology … Seriously?] by David Dischave. 2012. {{webarchive |url=https://web.archive.org/web/20140702113551/http://get.syr.edu/news_alt.aspx?recid=401 |date=July 2, 2014 }}</ref>
फुर्तीले सॉफ्टवेयर विकास के पैरोकार तर्क देते हैं कि वॉटरफॉल मॉडल सॉफ्टवेयर विकसित करने के लिए एक अप्रभावी प्रक्रिया है, कुछ संशयवादी सुझाव देते हैं कि वॉटरफॉल मॉडल एक गलत तर्क है जिसका उपयोग विशुद्ध रूप से वैकल्पिक विकास पद्धतियों को बाजार में करने के लिए किया जाता है।<ref>[http://get.syr.edu/news_alt.aspx?recid=401 A Waterfall Systems Development Methodology … Seriously?] by David Dischave. 2012. {{webarchive |url=https://web.archive.org/web/20140702113551/http://get.syr.edu/news_alt.aspx?recid=401 |date=July 2, 2014 }}</ref>
तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) चरण किसी परियोजना को ट्रैक पर रखने के लिए मील के पत्थर की कार्यक्रम संबंधी आवश्यकता को स्वीकार करते हैं, लेकिन चरणों के भीतर पुनरावृत्तियों (विशेष रूप से विषयों के भीतर) को प्रोत्साहित करते हैं। RUP चरणों को अक्सर जलप्रपात के रूप में संदर्भित किया जाता है।{{citation needed|date=March 2017}}
तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) चरण किसी परियोजना को ट्रैक पर रखने के लिए मील के पत्थर की कार्यक्रम संबंधी आवश्यकता को स्वीकार करते हैं, किन्तुचरणों के अंदर पुनरावृत्तियों (विशेष रूप से विषयों के अंदर) को प्रोत्साहित करते हैं। RUP चरणों को प्रायः जलप्रपात के रूप में संदर्भित किया जाता है।{{citation needed|date=March 2017}}
 




== संशोधित झरना मॉडल ==
== संशोधित झरना मॉडल ==
शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के जवाब में, कई 'संशोधित जलप्रपात मॉडल' पेश किए गए हैं। ये मॉडल शुद्ध जलप्रपात मॉडल की कुछ या सभी आलोचनाओं को संबोधित कर सकते हैं।
शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के उत्तर में, कई 'संशोधित जलप्रपात मॉडल' पेश किए गए हैं। ये मॉडल शुद्ध जलप्रपात मॉडल की कुछ या सभी आलोचनाओं को संबोधित कर सकते हैं।


इनमें रैपिड डेवलपमेंट मॉडल शामिल हैं जिन्हें [[स्टीव मैककोनेल]] संशोधित जलप्रपात कहते हैं:<ref name=rapid/>पीटर डेग्रेस का सैशिमी मॉडल (ओवरलैपिंग चरणों वाला झरना), सबप्रोजेक्ट्स वाला झरना, और जोखिम में कमी वाला झरना। अन्य सॉफ़्टवेयर विकास मॉडल संयोजन जैसे वृद्धिशील जलप्रपात मॉडल भी मौजूद हैं।<ref>{{cite web
इनमें रैपिड डेवलपमेंट मॉडल सम्मिलित  हैं जिन्हें [[स्टीव मैककोनेल]] संशोधित जलप्रपात कहते हैं:<ref name=rapid/> पीटर डेग्रेस का सैशिमी मॉडल (ओवरलैपिंग चरणों वाला झरना), सबप्रोजेक्ट्स वाला झरना, और कठिन परिस्थिति में कमी वाला झरना। अन्य सॉफ़्टवेयर विकास मॉडल संयोजन जैसे वृद्धिशील जलप्रपात मॉडल भी उपस्थितहैं।<ref>{{cite web
   | title=Methodology:design methods
   | title=Methodology:design methods
   | url=http://myprojects.kostigoff.net/methodology/development_models/development_models.htm  
   | url=http://myprojects.kostigoff.net/methodology/development_models/development_models.htm  
Line 58: Line 63:


== रॉयस का अंतिम मॉडल ==
== रॉयस का अंतिम मॉडल ==
[[File:1970_Royce_Managing_the_Development_of_Large_Software_Systems_Fig10.PNG|thumb|रॉयस अंतिम मॉडल]]विंस्टन डब्लू. रॉयस का अंतिम मॉडल, उनके शुरुआती जलप्रपात मॉडल पर उनका इच्छित सुधार, यह दर्शाता है कि फीडबैक कोड परीक्षण से डिजाइन तक (कोड के परीक्षण के रूप में डिजाइन में खामियों को उजागर किया जा सकता है) और डिजाइन से वापस आवश्यकताओं तक ले जा सकता है (चाहिए, और अक्सर होगा) विनिर्देश (डिजाइन समस्याओं के रूप में परस्पर विरोधी या अन्यथा असंतोषजनक / अनिर्दिष्ट आवश्यकताओं को हटाने की आवश्यकता हो सकती है)। उसी पेपर में रॉयस ने बड़ी मात्रा में प्रलेखन की भी वकालत की, यदि संभव हो तो दो बार काम करना ([[फ्रेड ब्रूक्स]] के समान भावना, मिथिकल मैन मंथ लिखने के लिए प्रसिद्ध, सॉफ्टवेयर [[परियोजना प्रबंधन]] में एक प्रभावशाली पुस्तक, जिसने एक को फेंकने की योजना बनाने की वकालत की दूर), और जितना संभव हो सके ग्राहक को शामिल करना ([[चरम कार्यक्रम]] के समान भावना)।
[[File:1970_Royce_Managing_the_Development_of_Large_Software_Systems_Fig10.PNG|thumb|रॉयस अंतिम मॉडल]]विंस्टन डब्लू. रॉयस का अंतिम मॉडल, उनके प्रारंभिक  जलप्रपात मॉडल पर उनका इच्छित सुधार, यह दर्शाता है कि फीडबैक कोड परीक्षण से डिजाइन तक (कोड के परीक्षण के रूप में डिजाइन में खामियों को उजागर किया जा सकता है) और डिजाइन से वापस आवश्यकताओं तक ले जा सकता है (चाहिए, और प्रायः होगा) विनिर्देश (डिजाइन समस्याओं के रूप में परस्पर विरोधी या अन्यथा असंतोषजनक / अनिर्दिष्ट आवश्यकताओं को हटाने की आवश्यकता हो सकती है)। उसी पेपर में रॉयस ने बड़ी मात्रा में प्रलेखन की भी वकालत की, यदि संभव हो तो दो बार काम करना ([[फ्रेड ब्रूक्स]] के समान भावना, मिथिकल मैन मंथ लिखने के लिए प्रसिद्ध, सॉफ्टवेयर [[परियोजना प्रबंधन]] में एक प्रभावशाली पुस्तक, जिसने एक को फेंकने की योजना बनाने की वकालत की दूर), और जितना संभव हो सके ग्राहक को सम्मिलित  करना ([[चरम कार्यक्रम]] के समान भावना)।


अंतिम मॉडल पर रॉयस के नोट हैं:
अंतिम मॉडल पर रॉयस के नोट हैं:
# विश्लेषण और कोडिंग शुरू होने से पहले पूरा कार्यक्रम डिजाइन
# विश्लेषण और कोडिंग प्रारंभ  होने से पहले पूरा कार्यक्रम डिजाइन
# दस्तावेज़ीकरण वर्तमान और पूर्ण होना चाहिए
# दस्तावेज़ीकरण वर्तमान और पूर्ण होना चाहिए
# काम को हो सके तो दो बार करें
# काम को हो सके तो दो बार करें
# परीक्षण की योजना बनाई, नियंत्रित और निगरानी की जानी चाहिए
# परीक्षण की योजना बनाई, नियंत्रित और निगरानी की जानी चाहिए
# ग्राहक को शामिल करें
# ग्राहक को सम्मिलित  करें


== यह भी देखें ==
== यह भी देखें ==

Revision as of 14:13, 28 February 2023

जलप्रपात मॉडल परियोजना गतिविधियों का रैखिक अनुक्रम चरणों में टूटना है, जिसका अर्थ है कि वे एक दूसरे पर पारित हो जाते हैं, जहां प्रत्येक चरण पिछले एक के डिलिवरेबल्स पर निर्भर करता है और कार्यों की विशेषज्ञता से मेल खाता है।[1] इंजीनियरिंग डिजाइन के कुछ क्षेत्रों के लिए दृष्टिकोण विशिष्ट है। सॉफ्टवेयर विकास प्रक्रिया में,[1] यह कम पुनरावृत्त और लचीले दृष्टिकोणों में से एक है, क्योंकि अवधारणा, दीक्षा, विश्लेषण, सॉफ्टवेर डिज़ाइन, सॉफ्टवेयर निर्माण, सॉफ्टवेयर परीक्षण, कार्यान्वयन और सॉफ्टवेयर रखरखाव के चरणों के माध्यम से प्रगति अधिक सीमा तक एक दिशा (एक झरने की तरह नीचे की ओर) में बहती है।[2][better source needed] जलप्रपात मॉडल प्रारंभिक प्रणाली विकास जीवन चक्र दृष्टिकोण है जिसका उपयोग सॉफ्टवेयर विकास में किया गया था।[citation needed] जलप्रपात विकास मॉडल की उत्पत्ति विनिर्माण और निर्माण उद्योगों में हुई,[citation needed] जहां अत्यधिक संरचित भौतिक वातावरण का कारणथा कि विकास प्रक्रिया में डिजाइन परिवर्तन निषेधात्मक रूप से महंगे हो गए थे।[citation needed] जब पहली बार सॉफ्टवेयर विकास के लिए अपनाया गया था, ज्ञान आधारित रचनात्मक कार्य के लिए कोई मान्यता प्राप्त विकल्प नहीं था।[3][better source needed]


इतिहास

सॉफ्टवेयर इंजीनियरिंग में ऐसे चरणों के उपयोग का वर्णन करने वाली पहली ज्ञात प्रस्तुति 29 जून 1956 को डिजिटल कंप्यूटर के लिए उन्नत प्रोग्रामिंग विधियों पर संगोष्ठी में फेलिक्स लोरेंजो टोरेस और हर्बर्ट डी. बेनिंगटन द्वारा आयोजित की गई थी।[citation needed].[4] यह प्रस्तुति अर्ध स्वचालित ग्राउंड पर्यावरण के लिए सॉफ्टवेयर के विकास के बारे में थी। 1983 में पेपर को बेनिंगटन द्वारा एक प्राक्कथन के साथ पुनर्प्रकाशित किया गया था जिसमें बताया गया था कि चरणों को कार्यों की विशेषज्ञता के अनुसार आयोजित किया गया था, और यह इंगित करते हुए कि प्रक्रिया वास्तव में एक सख्त टॉप-डाउन फैशन में नहीं की गई थी, किन्तुएक प्रोटोटाइप पर निर्भर थी। .[3]

चूंकि पेपर में वॉटरफॉल शब्द का उपयोग नहीं किया गया है, किन्तुप्रक्रिया का पहला औपचारिक विस्तृत आरेख बाद में वॉटरफॉल मॉडल के रूप में जाना जाता है[citation needed] विंस्टन डब्ल्यू रॉयस द्वारा 1970 के एक लेख के रूप में उद्धृत।[5][6][7] चूंकि उन्होंने यह भी अनुभूत किया कि इस तथ्य से उपजी बड़ी खामियां थीं कि परीक्षण केवल प्रक्रिया के अंत में हुआ, जिसे उन्होंने कठिन परिस्थिति भरा बताया और विफलता को आमंत्रित किया।[5]उनके पेपर के बाकी हिस्सों ने पांच चरणों की प्रारंभिक की जो उन्होंने अनुभूत किया कि अनछुए जलप्रपात दृष्टिकोण से जुड़े अधिकांश विकास कठिन परिस्थितिों को खत्म करने के लिए आवश्यक थे।[5]

रॉयस के पांच अतिरिक्त चरणों (जिसमें विकास के विभिन्न चरणों में पूर्ण प्रलेखन लिखना सम्मिलित था) ने कभी भी मुख्यधारा की पकड़ नहीं बनाई, किन्तुजलप्रपात के दृष्टिकोण का वर्णन करते समय उन्होंने जिसे एक त्रुटिपूर्ण प्रक्रिया माना उसका आरेख प्रारंभिक बिंदु बन गया।[8][better source needed] जलप्रपात शब्द का सबसे पहला प्रयोग बेल और थायर द्वारा 1976 के पेपर में किया गया हो सकता है।[9][better source needed] 1985 में, संयुक्त राज्य अमेरिका के रक्षा विभाग ने DOD-STD-2167A में इस दृष्टिकोण पर कब्जा कर लिया सॉफ्टवेयर विकास ठेकेदारों के साथ काम करने के लिए उनके मानक, जिसमें कहा गया है कि ठेकेदार एक सॉफ्टवेयर विकास चक्र प्रयुक्त करेगा जिसमें निम्नलिखित छह चरण सम्मिलित हैं: सॉफ्टवेयर आवश्यकता विश्लेषण, प्रारंभिक डिजाइन, विस्तृत डिजाइन, कोडिंग और यूनिट परीक्षण, एकीकरण और परीक्षण।[10]


मॉडल

रॉयस के मूल जलप्रपात मॉडल में[citation needed]क्रम में निम्नलिखित चरणों का पालन किया जाता है:

  1. प्रणाली आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताएँ: उत्पाद आवश्यकताएँ दस्तावेज़ में कैप्चर की गई हैं
  2. आवश्यकता विश्लेषण: जिसके परिणामस्वरूप मॉडल-संचालित सॉफ़्टवेयर विकास, डेटाबेस स्कीमा और व्यावसायिक नियम होते हैं
  3. सॉफ्टवेयर डिजाइन: सॉफ़्टवेयर वास्तुशिल्प के परिणामस्वरूप
  4. कंप्यूटर प्रोग्रामिंगमॉडल-संचालित सॉफ्टवेयर विकास, इकाई का परीक्षण और सॉफ्टवेयर का प्रणाली एकीकरण
  5. सॉफ्टवेयर परीक्षण: सॉफ्टवेयर बग की व्यवस्थित खोज और डिबगिंग
  6. कंप्यूटर ऑपरेटर: इंस्टालेशन (कंप्यूटर प्रोग्राम), आंकड़ों का विस्थापन, विधि ी सहायता और संपूर्ण प्रणाली का सॉफ्टवेयर रखरखाव

इस प्रकार जलप्रपात मॉडल का कहना है कि किसी को एक चरण में तभी जाना चाहिए जब उसके पिछले चरण की समीक्षा और सत्यापन किया जाए।

विभिन्न संशोधित जलप्रपात मॉडल (रॉयस के अंतिम मॉडल सहित), चूंकि, इस प्रक्रिया में सामान्य या बड़े बदलाव सम्मिलित हो सकते हैं।[5]इन विविधताओं में डाउनस्ट्रीम में खामियां पाए जाने के बाद पिछले चक्र में वापस आना, या डाउनस्ट्रीम चरणों को अपर्याप्त समझे जाने पर डिजाइन चरण में वापस आना सम्मिलित था।

सहायक तर्क

सॉफ्टवेयर उत्पादन चक्र में प्रारंभिक समय व्यतीत करने से बाद के चरणों में निवेश कम हो सकती है। उदाहरण के लिए, प्रारंभिक चरणों में पाई गई समस्या (जैसे आवश्यकताएं विनिर्देश) प्रक्रिया में बाद में पाए गए उसी बग की तुलना में ठीक करने के लिए सस्ता है (50 से 200 के कारक द्वारा)।[11] सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 20-40% समय, कोडिंग के लिए 30-40% समय, और शेष परीक्षण और कार्यान्वयन के लिए समर्पित समय के साथ एक परियोजना अनुसूची होती है। वास्तविक परियोजना संगठन को अत्यधिक संरचित होने की आवश्यकता है। अधिकांश मध्यम और बड़ी परियोजनाओं में प्रक्रियाओं और नियंत्रणों का एक विस्तृत सेट सम्मिलित होगा, जो परियोजना की प्रत्येक प्रक्रिया को विनियमित करते हैं।[12][failed verification] जलप्रपात मॉडल के लिए एक और तर्क यह है कि यह दस्तावेज़ीकरण (जैसे आवश्यकता दस्तावेज़ और डिज़ाइन दस्तावेज़) के साथ-साथ स्रोत कोड पर ज़ोर देता है।[citation needed] कम अच्छी तरह से डिजाइन और प्रलेखित कार्यप्रणाली में, यदि टीम के सदस्य परियोजना पूरी होने से पहले चले जाते हैं, तो ज्ञान खो जाता है, और परियोजना के लिए हानि से उबरना जटिल हो सकता है। यदि पूरी तरह से काम करने वाला डिज़ाइन दस्तावेज़ उपस्थितहै (जैसा कि बड़ा डिज़ाइन अप फ्रंट और वॉटरफॉल मॉडल का इरादा है), नए टीम के सदस्य या पूरी तरह से नई टीम भी दस्तावेज़ों को पढ़कर खुद को परिचित करने में सक्षम होनी चाहिए।[13]

जलप्रपात मॉडल एक संरचित दृष्टिकोण प्रदान करता है; मॉडल स्वयं असतत, आसानी से समझने योग्य और व्याख्या करने योग्य चरणों के माध्यम से रैखिक रूप से आगे बढ़ता है और इस प्रकार समझना आसान होता है; यह विकास प्रक्रिया में आसानी से पहचाने जाने योग्य मील के पत्थर भी प्रदान करता है। संभवतः यही कारण है कि जलप्रपात मॉडल का उपयोग कई सॉफ्टवेयर इंजीनियरिंग ग्रंथों और पाठ्यक्रमों में विकास मॉडल के प्रारंभिक उदाहरण के रूप में किया जाता है।[14]


आलोचना

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

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

शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के उत्तर में, संशोधित जलप्रपात मॉडल पेश किए गए, जैसे कि साशिमी (अतिव्यापी चरणों के साथ जलप्रपात), उपपरियोजनाओं के साथ जलप्रपात, और कठिन परिस्थिति में कमी के साथ जलप्रपात।[11]

संयुक्त राज्य अमेरिका के रक्षा विभाग जैसे कुछ संगठनों ने अब जलप्रपात-प्रकार की पद्धतियों के खिलाफ एक घोषित वरीयता दी है, जो 1994 में जारी MIL-STD-498 से प्रारंभ हुई, जो विकासवादी अधिग्रहण और पुनरावृत्त और वृद्धिशील विकास को प्रोत्साहित करती है।[18]

फुर्तीले सॉफ्टवेयर विकास के पैरोकार तर्क देते हैं कि वॉटरफॉल मॉडल सॉफ्टवेयर विकसित करने के लिए एक अप्रभावी प्रक्रिया है, कुछ संशयवादी सुझाव देते हैं कि वॉटरफॉल मॉडल एक गलत तर्क है जिसका उपयोग विशुद्ध रूप से वैकल्पिक विकास पद्धतियों को बाजार में करने के लिए किया जाता है।[19] तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) चरण किसी परियोजना को ट्रैक पर रखने के लिए मील के पत्थर की कार्यक्रम संबंधी आवश्यकता को स्वीकार करते हैं, किन्तुचरणों के अंदर पुनरावृत्तियों (विशेष रूप से विषयों के अंदर) को प्रोत्साहित करते हैं। RUP चरणों को प्रायः जलप्रपात के रूप में संदर्भित किया जाता है।[citation needed]


संशोधित झरना मॉडल

शुद्ध जलप्रपात मॉडल के साथ कथित समस्याओं के उत्तर में, कई 'संशोधित जलप्रपात मॉडल' पेश किए गए हैं। ये मॉडल शुद्ध जलप्रपात मॉडल की कुछ या सभी आलोचनाओं को संबोधित कर सकते हैं।

इनमें रैपिड डेवलपमेंट मॉडल सम्मिलित हैं जिन्हें स्टीव मैककोनेल संशोधित जलप्रपात कहते हैं:[11] पीटर डेग्रेस का सैशिमी मॉडल (ओवरलैपिंग चरणों वाला झरना), सबप्रोजेक्ट्स वाला झरना, और कठिन परिस्थिति में कमी वाला झरना। अन्य सॉफ़्टवेयर विकास मॉडल संयोजन जैसे वृद्धिशील जलप्रपात मॉडल भी उपस्थितहैं।[20]


रॉयस का अंतिम मॉडल

रॉयस अंतिम मॉडल

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

अंतिम मॉडल पर रॉयस के नोट हैं:

  1. विश्लेषण और कोडिंग प्रारंभ होने से पहले पूरा कार्यक्रम डिजाइन
  2. दस्तावेज़ीकरण वर्तमान और पूर्ण होना चाहिए
  3. काम को हो सके तो दो बार करें
  4. परीक्षण की योजना बनाई, नियंत्रित और निगरानी की जानी चाहिए
  5. ग्राहक को सम्मिलित करें

यह भी देखें


संदर्भ

  1. ↑ 1.0 1.1 Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). "The Waterfall Model in Large-Scale Development". Product-Focused Software Process Improvement. Lecture Notes in Business Information Processing (in English). Berlin, Heidelberg: Springer. 32: 386–400. doi:10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7.
  2. ↑ "The Traditional Waterfall Approach". www.umsl.edu. Retrieved 2022-02-23.
  3. ↑ 3.0 3.1 Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. S2CID 8632276. Retrieved 2011-03-21. Archived July 18, 2011, at the Wayback Machine
  4. ↑ United States, Navy Mathematical Computing Advisory Panel (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738
  5. ↑ 5.0 5.1 5.2 5.3 Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
  6. ↑ "Waterfall". Bremen University - Mathematics and Computer Science.
  7. ↑ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (eds.). "Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From?". Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Business Information Processing (in English). Berlin, Heidelberg: Springer. 9: 94–103. doi:10.1007/978-3-540-68255-4_10. ISBN 978-3-540-68255-4.
  8. ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
  9. ↑ Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
  10. ↑ "Military Standard Defense System Software Development" (PDF).
  11. ↑ 11.0 11.1 11.2 McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
  12. ↑ "Waterfall Software Development Model". 5 February 2014. Retrieved 11 August 2014.
  13. ↑ Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.
  14. ↑ Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.
  15. ↑ Parnas, David L.; Clements, Paul C. (1986). "A rational design process: How and why to fake it" (PDF). IEEE Transactions on Software Engineering (2): 251–257. doi:10.1109/TSE.1986.6312940. S2CID 5838439. Retrieved 2011-03-21.
  16. ↑ McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
  17. ↑ Ensmenger, Nathan (2010). The Computer Boys Take Over. p. 42. ISBN 978-0-262-05093-7.
  18. ↑ Larman, Craig; Basili, Victir (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer (June ed.). 36 (6): 47–56. doi:10.1109/MC.2003.1204375. S2CID 9240477.
  19. ↑ A Waterfall Systems Development Methodology … Seriously? by David Dischave. 2012. Archived July 2, 2014, at the Wayback Machine
  20. ↑ "Methodology:design methods".


बाहरी संबंध

Wikimedia Commons has media related to Waterfall models.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=जलप्रपात_मॉडल&oldid=104344’