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

सॉफ्टवेयर अभियांत्रिकी में ऐसे चरणों के उपयोग का वर्णन करने वाली पहली ज्ञात प्रस्तुति 29 जून 1956 को डिजिटल कंप्यूटर के लिए उन्नत प्रोग्रामिंग विधियों पर संगोष्ठी में [[फेलिक्स लोरेंजो टोरेस]] और हर्बर्ट डी. बेनिंगटन द्वारा आयोजित की गई थी।<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" />

चूंकि पेपर में झरना शब्द का उपयोग नहीं किया गया है, किन्तु प्रक्रिया का पहला औपचारिक विस्तृत आरेख जिसे बाद में झरना मॉडल के रूप में जाना जाता है अधिकांश विंस्टन डब्ल्यू रॉयस द्वारा 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>  

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

# सॉफ्टवेयर डिजाइन: जिसके परिणामस्वरूप [[सॉफ़्टवेयर वास्तुशिल्प]] होता है

# [[कंप्यूटर प्रोग्रामिंग]] [[मॉडल-संचालित सॉफ्टवेयर विकास]], [[इकाई का परीक्षण]] और सॉफ्टवेयर का [[प्रणाली एकीकरण]]

# [[कंप्यूटर ऑपरेटर]]: इंस्टालेशन (कंप्यूटर प्रोग्राम), [[आंकड़ों का विस्थापन]], विधि सहायता और संपूर्ण प्रणाली का सॉफ्टवेयर रखरखाव

विभिन्न संशोधित जलप्रपात मॉडल (रॉयस के अंतिम मॉडल सहित), चूंकि, इस प्रक्रिया में सामान्य या बड़े बदलाव सम्मिलित  हो सकते हैं।<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>

सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 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>

 

नए सॉफ़्टवेयर उत्पाद या फीचर को डिज़ाइन करते समय डिज़ाइनर भविष्य की कठिनाइयों से अवगत नहीं हो सकते हैं, इस स्थिति में डिज़ाइन को संशोधित करना उत्तम होता है, जो किसी नए खोजी गई बाधाओं, आवश्यकताओं या समस्याओं के लिए जिम्मेदार नहीं होता है।<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 name="rapid" />

 

 

फुर्तीले सॉफ्टवेयर विकास के पैरोकार तर्क देते हैं कि झरना मॉडल सॉफ्टवेयर विकसित करने के लिए अप्रभावी प्रक्रिया है, कुछ संशयवादी सुझाव देते हैं कि झरना मॉडल एक गलत तर्क है जिसका उपयोग विशुद्ध रूप से वैकल्पिक विकास पद्धतियों को बाजार में करने के लिए किया जाता है।<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>

तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) चरण किसी परियोजना को ट्रैक पर रखने के लिए मील के पत्थर की कार्यक्रम संबंधी आवश्यकता को स्वीकार करते हैं, किन्तुचरणों के अंदर पुनरावृत्तियों (विशेष रूप से विषयों के अंदर) को प्रोत्साहित करते हैं। आरयूपी चरणों को प्रायः जलप्रपात के रूप में संदर्भित किया जाता है।{{citation needed|date=March 2017}}

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

इनमें रैपिड डेवलपमेंट मॉडल सम्मिलित हैं, जिन्हें [[स्टीव मैककोनेल]] संशोधित जलप्रपात कहते हैं:<ref name=rapid/> पीटर डेग्रेस का सैशिमी मॉडल (अतिव्यापी चरणों वाला जलप्रपात), सबप्रोजेक्ट्स वाला झरना, और कठिन परिस्थिति में कमी वाला झरना। अन्य सॉफ़्टवेयर विकास मॉडल संयोजन जैसे वृद्धिशील जलप्रपात मॉडल भी उपस्थित होते हैं।<ref>{{cite web

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

# विश्लेषण और कोडिंग प्रारंभ होने से पहले पूरा कार्यक्रम डिजाइन

# परीक्षण की योजना नियंत्रित और निगरानी की जानी चाहिए

{{cmn|*[[सॉफ्टवेयर विकास दर्शन की सूची]]

*[[एजाइल सॉफ्टवेयर डेवलपमेंट]]

*[[बिग डिजाइन अप फ्रंट]]

*[[कैओस मॉडल]]

*[[देवऑप्स]]

*[[पुनरावृत्ति और वृद्धिशील विकास]]

*[[निगरानी रखरखाव जीवनचक्र]]

*[[ऑब्जेक्ट उन्मुख विश्लेषण और डिजाइन]]

*[[रैपिड अनुप्रयोग का विकास]]

*[[सॉफ्टवेयर विकास प्रक्रिया]]

*[[स्पाइरल मॉडल]]

*[[संरचित प्रणाली विश्लेषण और डिजाइन पद्धति]] (एसएसएडीएम)

*[[सिस्टम विकास पद्धति]]

*[[पारंपरिक इंजीनियरिंग]]

*[[वी-मॉडल (सॉफ्टवेयर डेवलपमेंट)|वी-मॉडल]]}}