वाटरफॉल मॉडल

Question

के विकल्प क्या हैं क्या आप कृपया एक ऐसी पद्धति दे सकते हैं जो झरना मॉडल के नुकसान को कम करने के लिए है?

Answer 1

यहाँ वाटरफॉल मॉडल के बारे में कुछ लिंक कर रहे हैं:

http://www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html

http://www.buzzle.com/editorials/3-13-2005-67039.asp

Answer 2

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

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

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

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

मूल रूप से RAD या DSDM था। फिर XP बैनर को टकराएं। अब Agile और Scrum और Kanban जैसी संबंधित चीजें हैं।

तो लोग वाटरफॉल विधि के साथ क्यों बने रहते हैं?

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

इसके अलावा Agile को ग्राहक के कर्मचारियों से समय की अधिक प्रतिबद्धता की आवश्यकता होती है, जो कई संगठन स्वीकार करने के लिए घृणित हैं। साथ ही बिल बनाने वाले लोग निर्णय लेने के लिए अपने जूनियर कर्मचारियों को सशक्त बनाने के इच्छुक नहीं हो सकते हैं। ग्राहक और उपयोगकर्ता के बीच एक महत्वपूर्ण अंतर है।

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

अंत में, ऐसी परियोजनाएं हैं जहां वाटरफाल अच्छी तरह से काम करता है। इन परियोजनाओं में ज्ञान डोमेन हैं जो ग्राहकों और डेवलपर्स दोनों द्वारा स्थिर और अच्छी तरह से समझ में आते हैं।

अंतिम शब्द

अपनी असफलताओं के बावजूद झरना सफलतापूर्वक कई परियोजनाओं जन्म दिया है। ऐसा इसलिए है क्योंकि कड़ी मेहनत, योग्यता और अखंडता पद्धति से अधिक महत्वपूर्ण हैं।

Answer 3

जलप्रपात मॉडल को 1 9 70 में डॉ। विंस्टन रॉयस द्वारा 'बड़े सॉफ्टवेयर सिस्टम के विकास के प्रबंधन' नामक एक पेपर में दस्तावेज किया गया था। अनुक्रमिक विकास पर मूल रूप से अपने विचारों की रूपरेखा। उनका विचार था कि सॉफ़्टवेयर को एक ऑटोमोबाइल के समान तरीके से बनाया जा सकता है, जहां वाहन अनुक्रमिक/रैखिक चरणों में एक साथ पाई जाती है।

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

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

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

ठीक है, तो अब विकल्प के लिए। वृद्धिशील मॉडल का वर्णन एलिस्टेयर कॉकबर्न (2008) द्वारा एक स्टेजिंग और शेड्यूलिंग रणनीति के रूप में किया गया है जिसमें विभिन्न भागों को विभिन्न समय या दरों पर विकसित किया जाता है और उस विशिष्ट भाग के पूरा होने पर एकीकृत किया जाता है।

मूल रूप से वृद्धिशील एक बहुत इस तरह दिखता है:

Analysis->Design->Code->Test 
    Analysis->Design->Code->Test 
    Analysis->Design->Code->Test 

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

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

Iterative approach diagram.

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

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

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

अन्य क्षेत्रों में देखना

यह कम रखने की कोशिश की लेकिन लोगों को सामान की इस तरह पर किताबें लिख सकते हैं और वहाँ बहुत चर्चा करने के लिए बहुत कुछ है Agile-> जमघट, एक्सट्रीम प्रोग्रामिंग, युग्मित प्रोग्रामिंग आदि शामिल होंगे। Incremental and Iterative

Answer 4

झरना विधि करने के लिए वैकल्पिक है "यह सही तरीका क्या कर रही":

पर एक नज़र होने के लायक हो सकता है।

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

Answer 5

मेरे सिर के ऊपर से, मैं तरीके झरना मॉडल की कमियों ख़ामोश रहना करने के बारे में सोच सकते हैं:

• प्रक्रिया ही स्वचालित पर सांकेतिक शब्दों में बदलनेवाला ध्यान लो। एक चरण और दूसरे के बीच संक्रमण स्वचालित करें, ताकि परिवर्तन स्वचालित रूप से कम या कम हो जाएंगे।
• प्रक्रिया को और अधिक द्विपक्षीय बनाएं। झरना मॉडल में एक प्रमुख विशेषता यह है कि परिवर्तन ऊपर से नीचे तक प्रवाह होता है। यह एक unidirectional प्रक्रिया है, और यह समस्या का हिस्सा है।

एक और बात जो मदद मिलेगी है (के रूप में किसी को पहले के एक जवाब में बताया गया) डेवलपर ग्राहक ज्ञान हासिल करने के लिए व्यापार शामिल तर्क का एक बेहतर समझ हासिल करने के लिए के लिए, और क्या ग्राहक चाहता है की, और है विकास प्रक्रिया की विशेषताओं के बारे में।

Answer 6

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

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

कानबान थोड़ा काउबॉय है, लेकिन मुझे लगता है कि अगर आप इसे स्टैंडअप के साथ जोड़ते हैं तो निश्चित रूप से यह अभी भी इसकी जगह है।

स्क्रम टीम पर दबाव डालने और टिकटों पर स्वामित्व प्राप्त करने के लिए बहुत अच्छा है। मैंने पाया है कि ज्यादातर जगहें इस के साथ जा रही हैं लेकिन इसका पतन कुछ लोगों के लिए बैठकों के साथ कुछ लोगों के ऊपर है। स्प्रिंट प्लानिंग मीटिंग्स, स्प्रिंट किकऑफ मीटिंग्स, दैनिक स्टैंडअप मीटिंग्स जो 20+ लोगों के साथ 1 घंटे तक चलती हैं, डेमो मीटिंग्स और फिर आखिरकार पोस्ट-मॉर्टम।

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