case study how eliminate flaws waterfall
चंचल जलप्रपात हाइब्रिड मॉडल
वॉटरफॉल मॉडल सॉफ्टवेयर विकास के लिए आदर्श विकल्प रहा है। इस मॉडल में, एक विचार एक अनुक्रमिक प्रक्रिया में प्रयोग करने योग्य सॉफ्टवेयर बन जाता है जो पहल, विश्लेषण, कार्यान्वयन, परीक्षण और रखरखाव के चरणों से गुजरता है।
लेकिन वाटरफॉल मॉडल के कुछ नुकसान हैं।
झरना मॉडल के मुद्दों को खत्म करने के लिए चुस्त सॉफ्टवेयर विकास विकसित हुआ। इसकी पूरी तरह से नई रूपरेखा है। जबकि झरना मॉडल में एक अनुक्रमिक डिजाइन है, चंचल मॉडल ने एक वृद्धिशील दृष्टिकोण का पालन किया।
जब क्लाइंट्स जो वाटरफॉल मॉडल का पालन करते थे, वह एजाइल में बदल जाता था, तो संक्रमण कई मुद्दों को अपने साथ लाता था। सॉफ्टवेयर विकास के लिए एक अलग दृष्टिकोण के लिए अक्षमता का कारण। अंत उत्पाद एक आपदा के रूप में निकला।
इस प्रकार एक नई पद्धति विकसित हुई है, जिसे pros हाइब्रिड ’कहा जा सकता है, ताकि एजाइल और वॉटरफॉल दोनों मॉडल के पेशेवरों को चुनकर एक मजबूत एंड-प्रोडक्ट सुनिश्चित किया जा सके।
आइए सबसे पहले वाटरफॉल और एजाइल डेवलपमेंट मॉडल के बारे में जानते हैं और फिर प्रत्येक के पेशेवरों और विपक्षों के साथ 'एजाइल वॉटरफॉल हाइब्रिड मॉडल' पर चलते हैं।
आप क्या सीखेंगे:
- झरना मॉडल
- फुर्तीली मॉडल
- सहयोगात्मक (हाइब्रिड) मॉडल
- चंचल जलप्रपात हाइब्रिड मॉडल - उदाहरण के द्वारा जानें - एक केस स्टडी
- हाइब्रिड मॉडल का उपयोग करके झरने और फुर्तीली विकास प्रक्रियाओं के दोषों को कैसे कम करें:
- निष्कर्ष:
- अनुशंसित पाठ
झरना मॉडल
वाटरफॉल मॉडल सॉफ्टवेयर विकसित करने के लिए एक दृष्टिकोण है जो एक परियोजना को सीमित चरणों में तोड़ता है। किसी को अगले चरण में तभी जाना चाहिए जब उसके पूर्ववर्ती चरण की समीक्षा और सत्यापन किया जाए।
झरना मॉडल में, चरण ओवरलैप नहीं होते हैं।
=> वाटरफॉल मॉडल के बारे में यहाँ और पढ़ें।
चित्र 1 में जलप्रपात मॉडल दिखाया गया है:
झरना मॉडल के लाभ:
- सरल और समझने में आसान और उपयोग।
- कठोर मॉडल - प्रत्येक चरण में विशिष्ट वितरण और समीक्षा प्रक्रियाएं होती हैं।
- दस्तावेज़ीकरण और कलाकृतियों को सावधानीपूर्वक बनाए रखा गया है।
- उन परियोजनाओं के लिए उपयुक्त जहां आवश्यकताओं को अच्छी तरह से समझा जाता है।
झरना मॉडल के नुकसान:
- उन परियोजनाओं के लिए उपयुक्त नहीं है जहां आवश्यकताओं को बदलने का जोखिम है।
- बाद के चरण में पता चलने पर दोषों को ठीक करने की लागत बहुत अधिक है।
- जटिल और लंबी परियोजनाओं के लिए एक अच्छा मॉडल नहीं है।
- जीवनचक्र के दौरान देर तक कोई भी कार्यशील सॉफ्टवेयर तैयार नहीं किया जाता है।
फुर्तीली मॉडल
विकिपीडिया एजाइल मॉडल को 'पुनरावृत्त और वृद्धिशील विकास पर आधारित सॉफ्टवेयर विकास विधियों का एक समूह के रूप में परिभाषित करता है, जहां आवश्यकताओं और समाधान स्वयं-आयोजन, क्रॉस-फ़ंक्शनल टीमों के बीच सहयोग के माध्यम से विकसित होते हैं।'
मॉडल के अपने सिद्धांत हैं जो प्रक्रियाओं को बैकसीट में लाने की प्रवृत्ति रखते हैं।
=> चुस्त कार्यप्रणाली पर अधिक लेख यहां पढ़ें।
(बढ़े हुए देखने के लिए चित्र पर क्लिक करें)
फुर्तीली मॉडल के लाभ:
- प्रक्रिया में ग्राहक की भागीदारी।
- उच्च आरओआई के रूप में कार्य सॉफ्टवेयर अक्सर दिया जाता है।
- आवश्यकताओं में देर से बदलाव को भी आसानी से समायोजित किया जा सकता है।
- उत्पाद और प्रक्रिया दोनों में निरंतर सुधार।
फुर्तीली मॉडल के नुकसान:
- डिजाइनिंग और प्रलेखन पर जोर देना।
- टीम स्थिर और कुशल होनी चाहिए।
सहयोगात्मक (हाइब्रिड) मॉडल
सहयोगात्मक मॉडल का उद्देश्य दोनों मॉडल - झरना और फुर्तीली को मिलाना है। वाटरफॉल और एजाइल दोनों दृष्टिकोण का उत्थान परियोजना की सफलता सुनिश्चित करता है। यह दोनों मॉडलों के नुकसान को दूर करता है; दोनों के फायदों को एक साथ लाते हुए।
सहयोगात्मक मॉडल को क्रियान्वित करके एक परियोजना में लागू किया जा सकता है:
तो सहयोगात्मक मॉडल को नीचे दिए अनुसार आरेखीय रूप से दर्शाया जा सकता है:
हाइब्रिड मॉडल के लाभ
- फुर्तीली और झरना दोनों प्रक्रियाओं के लाभों को जोड़ती है।
- उच्च-स्तरीय डिजाइन झरना सिद्धांतों को लागू करने के लिए तैयार किया जाता है।
- कोडिंग और परीक्षण चुस्त कार्यप्रणाली का उपयोग करके किया जाता है।
चंचल जलप्रपात हाइब्रिड मॉडल - उदाहरण के द्वारा जानें -एक मामले का अध्ययन
सॉफ्टवेयर फर्म, एबीसी सॉफ्टवेयर सेवा एक ग्राहक को सेवाएँ प्रदान करती है, एक विश्वविद्यालय जिसका नाम University XYZ University ’है, अपने सॉफ़्टवेयर (लाइव उत्पादन समर्थन) को विकसित करने, परीक्षण करने और बनाए रखने के लिए।
खाते की मुख्य विशेषताएं हैं:
- एबीसी सॉफ्टवेयर सर्विसेज को एक्सवाईजेड यूनिवर्सिटी के अनुप्रयोगों को अपग्रेड करना होगा। डेटाबेस को उन्नत करने की आवश्यकता है और सभी अनुप्रयोगों को बाजार में उपलब्ध नवीनतम तकनीक को फिर से विकसित करने की आवश्यकता है।
- अब तक, एबीसी सॉफ्टवेयर द्वारा संचालित सभी परियोजनाओं को झरना मॉडल में निष्पादित किया गया था।
- भारी यातायात और उच्च प्राथमिकता वाले दो अनुप्रयोगों को अब फिर से विकसित किया जाना था। पहला first ऑनलाइन पंजीकरण ’, दूसरा inations ऑनलाइन परीक्षा’।
- क्लाइंट XYZ विश्वविद्यालय अब इन अनुप्रयोगों को सॉफ्टवेयर विकास के फुर्तीले मॉडल का उपयोग करने पर काम करना चाहता था।
एबीसी सॉफ्टवेयर के लिए एक फुर्तीली मॉडल में पहली परियोजना ऑनलाइन पंजीकरण थी। इस परियोजना के निष्पादन के बाद, यह पूर्वव्यापी की एक श्रृंखला में महसूस किया गया था कि प्रक्रियाओं में कई खामियां थीं।
दूसरी परियोजना 'ऑनलाइन परीक्षाओं' को निष्पादित करते समय इन खामियों का ध्यान रखा गया था और इसलिए इसे हाइब्रिड मॉडल में निष्पादित किया गया था।
हाइब्रिड मॉडल का उपयोग करके झरने और फुर्तीली विकास प्रक्रियाओं के दोषों को कैसे कम करें:
आइए इन पर विस्तार से चर्चा करें।
# 1 कोई दस्तावेज़ीकरण नहीं:
फुर्तीले घोषणापत्र में चुस्त सिद्धांतों में से एक यह बताता है कि: फुर्तीली। व्यापक प्रलेखन पर कार्यशील सॉफ्टवेयर ’को अधिक मूल्य देती है। चंचल कार्यप्रणाली का मानना है कि प्रलेखन ‘बस मुश्किल से काफी अच्छा होना चाहिए’, और एक काम करने वाले सॉफ्टवेयर को बाहर करने के लिए अधिक जोर दिया जाता है। दस्तावेज़ीकरण पर बहुत प्रयास नहीं किया गया है, लेकिन XYZ विश्वविद्यालय जैसे खातों के लिए, जीवित परियोजनाओं पर पाए जाने वाले दोषों पर काम करने के लिए एक समर्पित समर्थन टीम के साथ, यह आदत एक बाधा के रूप में साबित हो सकती है यदि हम इसे दीर्घकालिक आधार पर विश्लेषण करते हैं।
वर्षों से, जब परियोजनाओं को जलप्रपात मॉडल में निष्पादित किया गया था, तो दस्तावेजों को बनाए रखा गया था और तदनुसार समर्थन टीम को समझने और काम करने के लिए अद्यतन किया गया था। सॉल्यूशन डिज़ाइन, टेक्निकल डिज़ाइन, वॉकथ्रू डॉक्यूमेंट आदि कुछ तैयार किए गए दस्तावेज़ थे। परियोजना समाप्त होने के बाद, उसी को समर्थन टीम में बदल दिया गया।
लेकिन reg ऑनलाइन पंजीकरण ’परियोजना के मामले में, इस तरह के कोई दस्तावेज तैयार नहीं किए गए थे और यह महंगा साबित हुआ था। जब परियोजना लाइव हो गई, तो कई टिकट एंड-यूज़र्स द्वारा उठाए गए थे और समर्थन टीम के पास कोई सुराग नहीं था कि उन पर कैसे काम किया जाए। टीम के पास संदर्भ के लिए कोई दस्तावेज नहीं था।
यह एक प्रमुख सबक था और अगली परियोजना के लिए inations ऑनलाइन परीक्षाओं के दस्तावेज लिखे और प्रभावी ढंग से परिवर्तित किए गए।
=> यहां पढ़ें कि प्रलेखन क्यों महत्वपूर्ण है
#दो। कोई UAT / एंड-टू-एंड परीक्षण:
सॉफ्टवेयर विकास के चुस्त मोड में, परीक्षकों को वेतन वृद्धि में परीक्षण करने के लिए बिल्ड मिलते हैं। ये बिल्ड तब तक एकीकृत होते रहते हैं जब तक कि अंतिम निर्माण पूरी तरह से नहीं हो जाता। परीक्षक प्रत्येक स्प्रिंट में कवर की गई आवश्यकताओं का परीक्षण करते हैं और उस निर्माण का प्रतिगमन परीक्षण करते रहते हैं जो ऊपर जोड़ता रहता है।
लेकिन सभी स्प्रिंट पूर्ण होने के बाद और अंतिम बिल्ड तैयार है और सभी एकीकृत हैं, परीक्षक को पूरी प्रणाली का परीक्षण करना चाहिए और एंड-टू-एंड परीक्षण करना चाहिए। यह पूरी तरह से नए माहौल में किया जाना चाहिए।
=> एक जीवित परियोजना पर परीक्षण समाप्त करने के लिए अंत।
इसके अपने फायदे हैं:
- पूरा सिस्टम एक नए वातावरण में तैनात है और परीक्षक पूर्ण प्रवाह का परीक्षण करता है।
- यह आत्मविश्वास का निर्माण करता है क्योंकि आखिरकार, बिल्ड को एक जीवित वातावरण में एक पूरे के रूप में तैनात करने की आवश्यकता होती है।
जब ऑनलाइन पंजीकरण परियोजना का परीक्षण किया गया था, तो यह परीक्षण वातावरण में किया गया था। सिस्टम परीक्षण और सभी दोषों के पुन: परीक्षण के बाद, इसे साइन-ऑफ के लिए घोषित किया गया था। आदर्श रूप से, सिस्टम परीक्षण के एक और चक्र के लिए इसे दूसरे वातावरण में प्रचारित नहीं किया गया था। (आदर्श रूप से, UAT सिस्टम टेस्टिंग के बाद होता है , लेकिन इस मामले में, UAT टीम के सदस्य परीक्षण के पहले चक्र में शामिल थे, इसलिए कोई दूसरा चक्र निर्धारित नहीं किया गया था)
जब ऑनलाइन परीक्षा परियोजना शुरू हुई, तो SIT (सिस्टम एकीकरण परीक्षण) किया गया और कोड को UAT वातावरण में पदोन्नत किया गया जहाँ परीक्षण का दूसरा चक्र किया गया। परिणाम: सभी उच्च प्राथमिकता वाले दोषों को पकड़ लिया गया और हल किया गया। गो-लाइव रिलीज़ से पहले बिल्ड स्थिर था।
# ३। नो स्क्रेम मास्टर:
जमघट मास्टर यह सुनिश्चित करने के लिए ज़िम्मेदार है कि एक टीम स्क्रम के मूल्यों और प्रथाओं द्वारा रहती है। स्क्रम मास्टर को टीम के लिए एक ऐसा कोच माना जाता है, जो टीम को संभवत: सबसे अच्छा काम करने में मदद करता है। स्क्रम मास्टर के रूप में भी सोचा जा सकता है प्रोसेस ओनर टीम के लिए।
एक स्क्रम मास्टर के बिना ऑनलाइन पंजीकरण टीम का गठन किया गया था। एक समर्पित स्क्राम मास्टर होने के महत्व को महत्वपूर्ण नहीं माना गया था। इससे कई मुद्दों का समाधान समय पर नहीं हो पाया और बदले में, परियोजना को पूरा करने का समय अक्सर समय सीमा पार कर गया।
हालाँकि, एक समर्पित स्क्रम मास्टर ऑनलाइन परीक्षाओं में शामिल था। परियोजना के मुद्दों और चुनौतियों को स्क्रैम मास्टर द्वारा ध्यान रखा गया था। परियोजना / स्प्रिंट रिपोर्ट तैयार की गई और टीम उनकी प्रगति देख सकती थी।
हैश तालिका c ++ लागू करना
इसके अलावा, उचित स्प्रिंट नियोजन बैठकें और स्प्रिंट पूर्वव्यापी बैठकें प्रत्येक स्प्रिंट के लिए हुईं जिससे टीम के प्रदर्शन में सुधार हुआ। टीम केवल अपने काम पर ध्यान केंद्रित कर रही थी और अपने काम को उस स्प्रिंट के लिए पूरा कर रही थी। सभी अतिरिक्त हाउसकीपिंग को स्क्रैम मास्टर द्वारा नियंत्रित किया गया था।
# ४। उत्पाद बैकलॉग में प्रोजेक्ट दस्तावेज़ परिवर्तित करना:
वाटरफॉल मॉडल में तैयार किए गए प्रारंभिक परियोजना दस्तावेज व्यावसायिक आवश्यकताओं के विनिर्देश (बीआरएस), उच्च-स्तरीय डिजाइन, कार्यात्मक डिजाइन आदि हैं। इन दस्तावेजों को कोडिंग, परीक्षण और कार्यान्वयन चरणों को निष्पादित करने के लिए उत्पाद बैकलॉग में बदलना होगा। चुस्त मोड में। यह एक काफी अहम कदम है।
उत्पाद बैकलॉग एक फुर्तीली परियोजना का प्रारंभिक बिंदु है। उत्पाद बैकलॉग आवश्यकताओं की एक प्राथमिकता वाली सूची है जो किसी उत्पाद के लिए बनाए रखी जाती है। इसमें फीचर्स, बग फिक्स, नॉन-फंक्शनल रिक्वायरमेंट आदि शामिल हैं। यह एक बढ़ता हुआ डॉक्यूमेंट है जो कस्टमर फीडबैक, चेंजिंग रिक्वायरमेंट्स आदि के आधार पर बड़ा और बेहतर हो जाता है।
किसी भी परियोजना की पहली कलाकृति होने के नाते, आवश्यकताओं को सूचीबद्ध करना और उन्हें प्राथमिकता देना सबसे महत्वपूर्ण है। उत्पाद बैकलॉग के लिए झरना परियोजना दस्तावेजों का रूपांतरण अपने आप में एक बड़ा काम है और इसके लिए ग्राहक / हितधारक के साथ-साथ पूरी टीम के विचार-मंथन की आवश्यकता होती है।
एक बार जब सभी आवश्यकताओं को सूचीबद्ध और ग्राहक द्वारा सहमति दे दी जाती है, तो अगला कार्य उन्हें स्प्रिंट में लेने के लिए प्राथमिकता देना है।
# 5 पता लगाने की क्षमता का मापदंड:
एक अन्य महत्वपूर्ण विरूपण साक्ष्य जो आमतौर पर जलप्रपात मॉडल में बनाए रखा जाता है, ट्रेसबिलिटी मैट्रिक्स है। ताकि यह सुनिश्चित करने के लिए कि कोई आवश्यकताएं छूट न जाएं; ट्रैसेबिलिटी मैट्रिक्स को भी डिज़ाइन और रखरखाव किया जाना चाहिए । आमतौर पर, फुर्तीली में ऐसी कोई मैट्रिक्स डिज़ाइन नहीं की जाती है।
यह किसी भी परियोजना में एक सर्वोत्तम अभ्यास है। उत्पाद बैकलॉग के समानांतर एक ट्रेसेबिलिटी मैट्रिक्स तैयार किया जाना चाहिए। और इसे उपयोगकर्ता स्वीकृति परीक्षण / एंड-टू-एंड परीक्षण के दौरान निष्पादित किए गए परीक्षण मामलों के खिलाफ जांच की जानी चाहिए (यह चरण मेरे अगले बिंदु में समझाया गया है)। यहां तक कि अगर किसी भी आवश्यकता को याद किया जाता है, तो इसे आसानी से विकास के देर के चरणों में भी शामिल किया जा सकता है क्योंकि फुर्तीली अतिरिक्त लचीलापन और अनुकूलन क्षमता प्रदान करती है।
ऑनलाइन पंजीकरण परियोजना के लाइव होने के बाद, एप्लिकेशन को अंतिम उपयोगकर्ताओं (जो छात्र पंजीकरण करना चाहते थे) द्वारा एक्सेस किया गया था। उन्हें आवेदन में बहुत सारे मुद्दों का सामना करना पड़ा। इससे उत्पादन समर्थन टीम को ढेर सारे टिकट मिले। उठाए गए टिकट को घटनाओं, समस्याओं या परिवर्तनों के रूप में वर्गीकृत किया जा सकता है। बहुत सारे मुद्दों को हल किया गया था, यह अनुमान लगाते हुए कि आवेदन स्थिर हो जाएगा। लेकिन फिर भी, बाद के रिलीज में एक दर्जन से अधिक परिवर्तन अनुरोध / संवर्द्धन की योजना बनाई गई थी। ये एन्हांसमेंट एप्लिकेशन को स्थिर करने और एंड-यूज़र अनुभव को बेहतर बनाने के लिए थे।
तो आखिरकार, परियोजना की लागत कई गुना बढ़ गई। इसलिए, यदि किसी परियोजना को ठीक से चुस्त करने के लिए संक्रमण नहीं किया जाता है, तो यह बजट को ओवरशूट करने का कारण बन सकता है। एजाइल के लिए एक परियोजना के पूरी तरह से संक्रमण की योजना बनाना बहुत आवश्यक है। इसके अलावा, योजना को उस हद तक पूरा किया जाना चाहिए, जब परियोजना को चुस्त मोड में निष्पादित किया जाना चाहिए। एक विशेष परियोजना के लिए उचित हाइब्रिड मॉडल तैयार किए जाने चाहिए।
एग्जाम एंट्री प्रोजेक्ट की शुरुआत से पहले, इस पहलू की अच्छी तरह से देखभाल की गई थी। एक हाइब्रिड मॉडल के बारे में सोचा गया था और यह निर्णय लिया गया था कि आवश्यकताओं के विश्लेषण चरण और उच्च-स्तरीय डिजाइन चरण को झरना मॉडल और फुर्तीले मॉडल के बाकी चरणों में निष्पादित किया जाना था।
अपनाए गए हाइब्रिड मॉडल को नीचे दिए गए सचित्र रूप से दर्शाया जा सकता है:
निष्कर्ष:
यह स्पष्ट है कि वाटरफॉल मॉडल और एजाइल मॉडल दोनों के अपने नुकसान हैं। तो, हाइब्रिड मॉडल का चयन करना काफी यथार्थवादी है, जो एक दृष्टिकोण है दोनों दुनिया के सर्वश्रेष्ठ का लाभ उठाते हुए।
किसी भी परियोजना की शुरुआत का सबसे महत्वपूर्ण पहलू उस मॉडल को तय करना है जिसे टीम अपनाने जा रही है। इसके लिए व्यापक योजना की आवश्यकता है। सॉफ्टवेयर मॉडल अपनाने में बजट, समय, संसाधन उपयोग, आवश्यकताओं की जटिलता आदि जैसे कारकों पर विचार किया जाना चाहिए।
हाइब्रिड मॉडल अभी भी एक नवजात अवस्था में है। जैसा कि अधिक से अधिक कंपनियां इसे अपनाएंगी, हम इस अवधारणा के बारे में अधिक जानेंगे।
चंचल घोषणापत्र हमें मूल्य के लिए पूछता है:
- व्यक्तियों और बातचीत प्रक्रियाओं और उपकरणों पर
- काम करने वाला सॉफ्टवेयर व्यापक प्रलेखन पर
- ग्राहक सहयोग अनुबंध पर बातचीत
- बदलने का जवाब एक योजना के बाद
जबकि, हाइब्रिड मॉडल इस 100% का पालन नहीं करता है। यह बताता है कि सभी पहलू समान महत्व के हैं। यह ग्राहकों / परियोजना प्रबंधकों पर निर्भर है कि वे किन पहलुओं को अधिक महत्व देते हैं और किन पहलुओं को वैधता देते हैं।
लेखक के बारे में: यह हर्षपाल सिंह का एक अतिथि लेख है। उनके पास 7+ साल का मैनुअल, डेटाबेस, स्वचालन और प्रदर्शन परीक्षण का अनुभव है और वर्तमान में एक प्रमुख एमएनसी में टीम लीड के रूप में काम कर रहा है। उन्होंने झरना, फुर्तीली और संकर विकास मॉडल के बाद कई क्यूए परियोजनाओं पर काम किया है।
क्या आपके पास इस हाइब्रिड विकास और परीक्षण मॉडल पर काम करने का कोई अनुभव है? टिप्पणियों में चर्चा करते हैं।
अनुशंसित पाठ
- फुर्तीली बनाम झरना: आपकी परियोजना के लिए सबसे अच्छी पद्धति कौन सी है?
- एसडीएलसी झरना मॉडल क्या है?
- ज़ेफियर एंटरप्राइज टेस्ट मैनेजमेंट टूल रिव्यू - एजाइल टूल में वॉटरफॉल मॉडल एसेट्स का उपयोग कैसे करें
- सर्पिल मॉडल - एसडीएलसी सर्पिल मॉडल क्या है?
- 4 कदम एजाइल प्रक्रिया के लिए सफल संक्रमण के लिए चुस्त परीक्षण मानसिकता विकसित करना
- JIRA एजाइल ट्यूटोरियल: JIRA का उपयोग कैसे करें फुर्तीली परियोजनाओं के प्रबंधन के लिए
- एसडीएलसी (सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल) चरण, तरीके, प्रक्रिया और मॉडल
- एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स