वाटरफॉल मॉडल

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

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

वाटरफॉल मॉडल का सबसे पहला औपचारिक वर्णन, प्रायः विंस्टन डब्ल्यू. रॉयस (1929-1995) द्वारा 1970 में प्रकाशित एक लेख से उद्धृत किया गया है,^[1] हालांकि रॉयस ने इस लेख में 'वाटरफॉल' संज्ञा का प्रयोग नहीं किया था। रॉयस ने इस मॉडल को एक त्रुटिपूर्ण और बेकार मॉडल (Royce 1970) के एक उदाहरण के रूप में पेश किया था। आमतौर पर प्रयोग किए जाने वाले किसी सॉफ्टवेयर प्रैक्टिस की आलोचना करने के एक तरीके के रूप में — सॉफ्टवेयर डेवलपमेंट के बारे में लिखित रूप में किसी संज्ञा को आमतौर पर प्रयोग करने का यही वास्तविक तरीका है।^[2]

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

1. आवश्यकताओं के विनिर्देश
2. डिजाइन
3. निर्माण (AKA कार्यान्वयन या कूट लेखन)
4. एकीकरण
5. परीक्षण और दोषमार्जन (debugging)
6. स्थापन
7. अनुरक्षण

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

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

सॉफ्टवेयर निर्माण चक्र के आरंभ में बिताए गए समय से बाद के चरणों में अधिक से अधिक अर्थव्यवस्था का मार्ग प्रशस्त हो सकता है। ऐसा दिखाया जा चुका है कि प्रारंभिक चरणों (जैसे आवश्यकताओं के विनिर्देश या डिजाइन) में पाया गया बग, प्रक्रिया में बाद में पाए गए वैसे ही बग की तुलना में पैसे, प्रयास और समय की दृष्टि से फिक्स करने के लिए सस्ता होता है। ([1996 मैककॉनल], पृष्ठ 72, अनुमान है कि निर्माण या रखरखाव तक असंसूचित छोड़े गए आवश्यकताओं के एक दोष को फिक्स करने में आवश्यकताओं के समय फिक्स करने की लागत से 50 से 200 गुना ज्यादा खर्च होगा। ") एक चरण उदाहरण ले, अगर एक प्रोग्राम डिजाइन को कार्यान्वित करना असंभव हो जाता है तो महीनों बाद इसका एहसास करने की अपेक्षा इसे डिजाइन चरण में ही डिजाइन को फिक्स कर लेना ज्यादा आसान होता है जब कार्यक्रम के घटकों को एकीकृत किया जा रहा हो क्योंकि एक बेकार डिजाइन के कारण अब तक किया गया सारा काम बिगड़ जाता है।

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

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

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

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

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

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

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

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

"मैनेजिंग द डेवलपमेंट ऑफ लार्ज सॉफ्टवेयर सिस्टम्स"^[3], प्रथम पत्र जिसमें वाटरफॉल मॉडल का वर्णन है, में डॉ॰ विंस्टन डब्ल्यू रॉयस ने भी सर्वसामान्य रूप को "रिस्की ऐंड इन्वाईट्स फेल्योर" (जोखिम भरा और विफलता को आमंत्रित करने वाला) के रूप में वर्णन किया है।

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

"ए रैशनल डिजाइन प्रोसेस: हाउ ऐंड व्हाइ टु फेक इट" में डेविड पार्नस ने लिखा है:^[4]

"[सिस्टम के] के कई विवरणों का पता हमलोगों को तभी चल पाता हैं जब हमलोग [सिस्टम के] कार्यान्वयन में प्रगति करते हैं। जिन कुछ चीज़ों को हमलोग सीखते हैं वे हमारे डिजाइन को अमान्य कर देते हैं और हमलोगों को उस पर जरूर नज़र रखना चाहिए."

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

शुद्ध वाटरफॉल मॉडल के साथ कथित समस्याओं के प्रतिक्रियास्वरूप, कई संशोधित वाटरफॉल मॉडलों को प्रस्तुत किया गया है। ये मॉडल, शुद्ध वाटरफॉल मॉडल के कुछ या सभी आलोचनाओं को संबोधित कर सकते हैं।^[] स्टीव मैककॉनल ने अपनी पुस्तक, Rapid Development: Taming Wild Software Schedules के "लाइफसाइकिल प्लानिंग" अध्याय में कई अलग-अलग मॉडलों को सम्मिलित किया है।

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

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

• ऐजाइल सॉफ्टवेयर डेवलपमेंट
• बिग डिज़ाइन अप फ्रंट
• केऑस मॉडल
• इटेरेटिव ऐंड इन्क्रेमेंटल डेवलपमेंट
• इटरफौल डेवलपमेंट
• रैपिड एप्लीकेशन डेवलपमेंट
• सॉफ्टवेयर डेवलपमेंट प्रोसेस
• स्पिरल मॉडल
• सिस्टम डेवलपमेंट मेथोडोलॉजी
• वी-मॉडल
• डुअल वी मॉडल
• सॉफ्टवेयर डेवलपमेंट फिलोसोफिस की सूची

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

• McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. आई॰ऍस॰बी॰ऍन॰ 0-7356-0535-1.
• McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. आई॰ऍस॰बी॰ऍन॰ 1-55615-484-4.
• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. आई॰ऍस॰बी॰ऍन॰ 1-55615-900-5.
• पर्नस, डेविड, रैशनल डिज़ाइन प्रक्रिया और इसकी कैसी नक़ल की जाती है (PDF) एक ऐसा प्रभावशाली पत्र जो इस विचार की आलोचना करता है कि सॉफ्टवेयर निर्माण का कार्य पूर्ण रूप से असतत चरणों में हो सकता है।
• Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1-9, <http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf>.
• जोएल स्पोलस्काई ऑन बिग डिज़ाइन अप फ्रंट
• जोएल स्पोलस्काई - "डेली बिल्ड्स आर योर फ्रेंड"
• "लोग अभी भी वाटरफॉल मॉडल में क्यों विश्वास करते हैं"
• सिस्टम्स डेवलपमेंट के लिए मानक वाटरफॉल मॉडल NASA वेबपेज, 10 मार्च 2005 को [[इंटरनेट

आर्काइव]] में संग्रहीत.

• पैरामेट्रिक कॉस्ट एस्टीमेटिंग हैण्डबुक, वाटरफॉल मॉडल पर आधारित NASA वेबपेज, 8 मार्च 2005 को इंटरनेट आर्काइव में संग्रहीत.

• सोफ्टवेयर डेवलपमेंट के वाटरफॉल मॉडल के पक्ष और विपक्ष को समझना Archived 2013-01-02 at archive.today
• "वाटरफॉल मॉडल को हानिकारक माना गया"
• प्रोजेक्ट लाइफसाइकल मॉडल: वे किस तरह से भिन्न है और उन्हें किस समय प्रयोग करना चाहिए
• RUP के साथ वाटरफॉल की छानबीन, फिलिप क्रुचन
• रिअलिस्टक सॉफ्टवेयर डेवलपमेंट के लिए वाटरफॉल मैनिफेस्टो
• C-RUP के वितरण और तीव्र व्यवसाय परिवर्तन के समर्थन के लिए CSC और IBM रैशनल का गठबंधन