जलप्रपात मॉडल

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

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

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

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

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

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

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

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

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

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

संयुक्त राज्य अमेरिका के रक्षा विभाग जैसे कुछ संगठनों ने अब जलप्रपात-प्रकार की पद्धतियों के खिलाफ एक घोषित वरीयता दी है, जो 1994 में जारी MIL-STD-498 से शुरू हुई, जो विकासवादी अधिग्रहण और पुनरावृत्त और वृद्धिशील विकास को प्रोत्साहित करती है। फुर्तीले सॉफ्टवेयर विकास के पैरोकार तर्क देते हैं कि वॉटरफॉल मॉडल सॉफ्टवेयर विकसित करने के लिए एक अप्रभावी प्रक्रिया है, कुछ संशयवादी सुझाव देते हैं कि वॉटरफॉल मॉडल एक गलत तर्क है जिसका उपयोग विशुद्ध रूप से वैकल्पिक विकास पद्धतियों को बाजार में करने के लिए किया जाता है। तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) चरण किसी परियोजना को ट्रैक पर रखने के लिए मील के पत्थर की कार्यक्रम संबंधी आवश्यकता को स्वीकार करते हैं, लेकिन चरणों के भीतर पुनरावृत्तियों (विशेष रूप से विषयों के भीतर) को प्रोत्साहित करते हैं। RUP चरणों को अक्सर जलप्रपात के रूप में संदर्भित किया जाता है।

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

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

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

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

यह भी देखें
• List of software development philosophies

• Agile software development

• Big Design Up Front

• Chaos model

• DevOps

• Iterative and incremental development

• Monitoring Maintenance Lifecycle

• Object-oriented analysis and design

• Rapid application development

• Software development process

• Spiral model

• Structured Systems Analysis and Design Method (SSADM)

• System development methodology

• Traditional engineering

• V-model

बाहरी संबंध

 * Understanding the pros and cons of the Waterfall Model of software development
 * Project lifecycle models: how they differ and when to use them
 * Going Over the Waterfall with the RUP by Philippe Kruchten
 * CSC and IBM Rational join to deliver C-RUP and support rapid business change
 * WaterFall
 *