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

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

इतिहास
सॉफ्टवेयर इंजीनियरिंग में ऐसे चरणों के उपयोग का वर्णन करने वाली पहली ज्ञात प्रस्तुति 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
 *