Waterfall मॉडल

Waterfall मॉडल क्या है

Waterfall मॉडल को प्रोजेक्ट मैनेजमेंट के लिए एक क्लासिक अप्रोच कहा जाता है, जो सटीकता से योजना बनाने, बारीकी से पेपर वर्क करने और टर्म्स ऑफ रेफरेंस, डेडलाइन और बजट का सख्ती से पालन करने पर आधारित है।

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

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

Waterfall मॉडल किस प्रकार काम करता है

Waterfall मॉडल के आधार पर काम करने वाले वर्किंग ग्रुप और टीम इसके मुख्य सिद्धांतों का पालन करते हैं, जो कि इस प्रकार हैं:

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

• आपको पिछले स्टेज को पूरा किए बिना डेवलपमेंट के एक नए स्टेज में नहीं जाना चाहिए। किसी भी स्थिति में आपको स्टेजस को छोड़ना नहीं चाहिए और नियोजित कार्य योजना से विचलित नहीं होना चाहिए।

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

• टेस्टिंग स्टेज में ही गलतियों की पहचान और उनमें सुधर होता है, न कि प्रोडक्ट के डेवलपमेंट के दौरान।

• प्रोडक्ट के निर्माण में केवल डेवलपर्स भाग लेते हैं। ऑर्डर देने वाला, यानि कि क्लाइंट, और साथ ही संभावित ऑडियंस इसमें भाग नहीं लेते हैं। क्लाइंट का काम केवल टेक्निकल असाइनमेंट निर्धारित करना होता है, जिसके बाद वह प्रक्रिया में हस्तक्षेप नहीं करता है।

• कोई पुनरावृत्ति नहीं है, अर्थात, प्रोडक्ट का डेवलपमेंट प्रॉसेस अविभाज्य है, यह अलग वर्क साइकिल में विभाजित नहीं होता, बल्कि इसका मलतब डेडलाइन के अनुसार एक स्टेज से दूसरे स्टेज में क्रमिक रूप से जाना है।

Waterfall मॉडल के अनुसार प्रोडक्ट डेवलपमेंट के स्टेज

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

स्टेज 1. आवश्यकताओं को लिखना

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

स्टेज 2. तैयार की गई आवश्यकताओं का विश्लेषण और अगले स्टेजस की योजना

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

स्टेज 3. डिजाइन

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

स्टेज 4. डेवलपमेंट

प्लान और टेक्निकल असाइनमेंट के साथ-साथ पिछले स्टेज में बनाए गए लेआउट और डिज़ाइन के अनुसार, एक नया प्रोडक्ट डवलप किया जाता है। यह कहा जा सकता है कि जो विचार पहले के स्टेजस में सैद्धांतिक या रेखांकित थे, उन्हें अमल में लाया जाता है।

स्टेज 5. टेस्टिंग

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

स्टेज 6. अमल करना

टेस्टिंग के परिणामस्वरूप गलतियों का पता लगाए जाने और ठीक किये जाने के बाद, प्रोजेक्ट क्लाइंट को दे दिया जाता है। हालांकि, भविष्य में, प्रोडक्ट के डेवलपमेंट पर निगरानी करना जरूरी है।

स्टेज 7. रखरखाव

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

Agile और Waterfall मॉडल के बीच अंतर

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

इस प्रकार, Agile लचीले दृष्टिकोणों और तकनीकों का एक ग्रुप है, इसके मूल सिद्धांत निम्नलिखित हैं:

• लोग डिवाइस से अधिक महत्वपूर्ण हैं।

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

• मुख्य लक्ष्य - एक क्वालिटी का प्रोडक्ट है।

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

• क्लाइंट के साथ कांटेक्ट के अधिक पॉइंट।

Agile के सिद्धांतों के अनुसार, न केवल डेवेलपर्स, बल्कि ग्राहक भी उत्पाद बनाने की प्रक्रिया में शामिल होते हैं। इसके अलावा, इस तकनीक में प्रोडक्ट डेवलपमेंट के सभी स्टेजस में क्लाइंट्स की सक्रिय भागीदारी शामिल है।

• प्रयोग।

Agile टेक्नोलॉजी को एम्पिरिकल कहा जाता है, क्योंकि वे देखरेख, अनुभव और प्रयोग पर आधारित होती हैं। इस प्रकार, इस टेक्नोलॉजी में अप्रत्याशित बदलाव, प्रयोग और योजना से विचलन स्वीकार्य होते हैं।

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

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

Waterfall मॉडल के फायदे और नुकसान

ऐसे मॉडल के निम्नलिखित फायदे होते हैं:

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

• टास्क और रिसोर्सेज का उचित वितरण। प्रक्रियाओं की सटीकता और निश्चितता पूरे प्रोजेक्ट में समय, ऊर्जा, सामग्री और वित्तीय संसाधनों को ध्यान में रख कर कुशल योजना बनाने में मदद करती है।

• कोई बाहरी हस्तक्षेप नहीं। अर्थात्, ग्राहक डेवलपमेंट में भाग नहीं लेता है, मध्यवर्ती नतीजे नहीं देखता है और टेक्निकल असाइनमेंट के बनने के बाद अपने खुद के समायोजन नहीं करता है। उस अवस्था में यह एक फायदा है, जब ग्राहक वर्किंग ग्रुप के साथ लगातार संपर्क में नहीं रह सकता।

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

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

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

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

• लचीलेपन की कमी। यदि किसी स्टेज में समस्याएँ उत्पन्न होंगी या फिर जरूरते बदल जाएंगी, तो पूरी प्रक्रिया को शुरू से शुरू करना जरुरी होगा।

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

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

Waterfall मॉडल के उपयोग करने का सबसे अच्छा समय कब होता है

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

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

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