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

From Vigyanwiki
No edit summary
No edit summary
Line 17: Line 17:
# प्रणाली आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताएँ: उत्पाद आवश्यकताएँ दस्तावेज़ में कैप्चर की गई हैं
# प्रणाली आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताएँ: उत्पाद आवश्यकताएँ दस्तावेज़ में कैप्चर की गई हैं
# आवश्यकता विश्लेषण: जिसके परिणामस्वरूप मॉडल-संचालित सॉफ़्टवेयर विकास, [[डेटाबेस स्कीमा]] और व्यावसायिक नियम होते हैं
# आवश्यकता विश्लेषण: जिसके परिणामस्वरूप मॉडल-संचालित सॉफ़्टवेयर विकास, [[डेटाबेस स्कीमा]] और व्यावसायिक नियम होते हैं
# सॉफ्टवेयर डिजाइन: [[सॉफ़्टवेयर वास्तुशिल्प]] के परिणामस्वरूप
# सॉफ्टवेयर डिजाइन: जिसके परिणामस्वरूप [[सॉफ़्टवेयर वास्तुशिल्प]] होता है
# [[कंप्यूटर प्रोग्रामिंग]][[मॉडल-संचालित सॉफ्टवेयर विकास]], [[इकाई का परीक्षण]] और सॉफ्टवेयर का [[प्रणाली एकीकरण]]
# [[कंप्यूटर प्रोग्रामिंग]] [[मॉडल-संचालित सॉफ्टवेयर विकास]], [[इकाई का परीक्षण]] और सॉफ्टवेयर का [[प्रणाली एकीकरण]]
# सॉफ्टवेयर परीक्षण: [[सॉफ्टवेयर बग]] की व्यवस्थित खोज और [[डिबगिंग]]
# सॉफ्टवेयर परीक्षण: [[सॉफ्टवेयर बग]] की व्यवस्थित खोज और [[डिबगिंग]]
# [[कंप्यूटर ऑपरेटर]]: इंस्टालेशन (कंप्यूटर प्रोग्राम), [[आंकड़ों का विस्थापन]], विधि ी सहायता और संपूर्ण प्रणाली का सॉफ्टवेयर रखरखाव
# [[कंप्यूटर ऑपरेटर]]: इंस्टालेशन (कंप्यूटर प्रोग्राम), [[आंकड़ों का विस्थापन]], विधि सहायता और संपूर्ण प्रणाली का सॉफ्टवेयर रखरखाव


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


विभिन्न संशोधित जलप्रपात मॉडल (रॉयस के अंतिम मॉडल सहित), चूंकि, इस प्रक्रिया में सामान्य या बड़े बदलाव सम्मिलित  हो सकते हैं।<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>
जल प्रपात मॉडल के लिए एक और तर्क यह है कि यह दस्तावेज़ीकरण (जैसे आवश्यकता दस्तावेज़ और डिज़ाइन दस्तावेज़) के साथ-साथ स्रोत कोड पर ज़ोर देता है। कम अच्छी तरह से डिजाइन और प्रलेखित कार्यप्रणाली में, यदि टीम के सदस्य परियोजना पूरी होने से पहले चले जाते हैं, तो ज्ञान खो जाता है, और परियोजना के लिए हानि से उबरना  जटिल हो सकता है। यदि पूरी तरह से काम करने वाला डिज़ाइन दस्तावेज़ उपस्थितहै (जैसा कि [[बड़ा डिज़ाइन अप फ्रंट]] और झरना मॉडल का इरादा है), नए टीम के सदस्य या पूरी तरह से नई टीम भी दस्तावेज़ों को पढ़कर खुद को परिचित करने में सक्षम होनी चाहिए।<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>
सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 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 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>


== आलोचना ==
== आलोचना ==

Revision as of 09:02, 1 March 2023

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

इतिहास

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

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

रॉयस के पांच अतिरिक्त चरणों (जिसमें विकास के विभिन्न चरणों में पूर्ण प्रलेखन लिखना सम्मिलित था) ने कभी भी मुख्यधारा की पकड़ नहीं बनाई, किन्तुजलप्रपात के दृष्टिकोण का वर्णन करते समय उन्होंने जिसे त्रुटिपूर्ण प्रक्रिया माना उसका आरेख प्रारंभिक बिंदु बन गया।[8]

जलप्रपात शब्द का सबसे पहला प्रयोग बेल और थायर द्वारा 1976 के पेपर में किया गया हो सकता है।[9]

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

मॉडल

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

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

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

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

सहायक तर्क

सॉफ्टवेयर उत्पादन चक्र में प्रारंभिक समय व्यतीत करने से बाद के चरणों में निवेश कम हो सकती है। उदाहरण के लिए, प्रारंभिक चरणों (जैसे आवश्यकताएं विनिर्देश) में पाई गई समस्या प्रक्रिया (50 से 200 के कारक द्वारा) में बाद में पाए गए उसी बग की तुलना में ठीक करने के लिए सस्ता है।[11]

सामान्य व्यवहार में, जलप्रपात कार्यप्रणालियों के परिणामस्वरूप पहले दो चरणों के लिए 20-40% समय, कोडिंग के लिए 30-40% समय, और शेष परीक्षण और कार्यान्वयन के लिए समर्पित समय के साथ परियोजना अनुसूची होती है। वास्तविकिक परियोजना संगठन को अत्यधिक संरचित होने की आवश्यकता है। अधिकांश मध्यम और बड़ी परियोजनाओं में प्रक्रियाओं और नियंत्रणों का विस्तृत सेट सम्मिलित होगा, जो परियोजना की प्रत्येक प्रक्रिया को विनियमित करते हैं।[12]

जल प्रपात मॉडल के लिए एक और तर्क यह है कि यह दस्तावेज़ीकरण (जैसे आवश्यकता दस्तावेज़ और डिज़ाइन दस्तावेज़) के साथ-साथ स्रोत कोड पर ज़ोर देता है। कम अच्छी तरह से डिजाइन और प्रलेखित कार्यप्रणाली में, यदि टीम के सदस्य परियोजना पूरी होने से पहले चले जाते हैं, तो ज्ञान खो जाता है, और परियोजना के लिए हानि से उबरना जटिल हो सकता है। यदि पूरी तरह से काम करने वाला डिज़ाइन दस्तावेज़ उपस्थितहै (जैसा कि बड़ा डिज़ाइन अप फ्रंट और झरना मॉडल का इरादा है), नए टीम के सदस्य या पूरी तरह से नई टीम भी दस्तावेज़ों को पढ़कर स्वयं को परिचित करने में सक्षम होनी चाहिए।[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=104350’