वॉटरफॉल मॉडल की समस्याएं क्या हैं?

वॉटरफॉल मॉडल इंजीनियरिंग डिजाइन के कुछ क्षेत्रों के लिए एक आपेक्षिक रूप से रैखिक अनुक्रमिक डिजाइन दृष्टिकोण है।

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

1. आवश्यकताएं

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

2. डिजाइनिंग

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

3. कार्यान्वयन

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

4. सत्यापन

यह विधि का वह भाग है जहां गुणवत्ता सुनिश्चितता वाले लोग आते हैं ताकि यह सुनिश्चित किया जा सके कि विकास टीम ने कोई गलती नहीं की है। यह वह भाग भी है जहां लोग यह जानते हैं कि उनकी योजना में क्या काम कर रहा है और क्या नहीं कर रहा है।

ध्यान दें कि

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

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

वॉटरफॉल की समस्या क्या है?

प्रारंभिक आवश्यकताओं की समस्या — योजना बनाम वास्तविकता

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

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

इसलिए, यह गारंटी नहीं है कि संगठन द्वारा सोची गई आवश्यकताएं वास्तव में काम करेंगी। इस बिंदु से आपको यह बात समझ में आएगी कि वॉटरफॉल मॉडल में निम्नलिखित समस्याएं हैं:

1.लोग अंधाधुंध योजनाओं का पालन करते हैं।

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

2. अनुक्रमिक प्रक्रिया और बदलाव महंगे हो जाते हैं

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

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

3. अंतिम उपयोगकर्ता नहीं जानते कि उन्हें क्या चाहिए।

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

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

4. गुणवत्ता के लिए परीक्षण में कमी आ सकती है।

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

5. आप कभी नहीं जान पाएंगे कि आप वास्तव में किस चरण पर हैं।

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

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

वॉटरफॉल की समस्या क्या है?

संबंधित संसाधन