agile vs waterfall which is best methodology
विंडोज़ 10 पर धारित फ़ाइलों को कैसे खोलें
फुर्तीली और झरना के तरीकों के बारे में सभी जानें, विभिन्न प्रकार के एसडीएलसी मॉडल और जलप्रपात बनाम फुर्तीली विकास मॉडल के बीच का अंतर और साथ ही परीक्षण:
यह निर्णय लेने के लिए इस जानकारीपूर्ण लेख को पढ़ें कि प्रत्येक के पेशेवरों और विपक्षों के आधार पर आपकी परियोजना के लिए सबसे उपयुक्त मॉडल कौन सा है।
वॉटरफॉल मॉडल और एजाइल मॉडल सॉफ्टवेयर डेवलपमेंट लाइफ साइकल (एसडीएलसी) के प्रकार हैं। ये सॉफ़्टवेयर उद्योग द्वारा सॉफ़्टवेयर को डिज़ाइन, विकसित और परीक्षण करने के लिए उपयोग की जाने वाली प्रक्रिया है।
एसडीएलसी का पालन करके, हम ग्राहकों की अपेक्षाओं को प्राप्त कर सकते हैं, दिए गए समय सीमा के भीतर परियोजना को पूरा कर सकते हैं, और लागत का अनुमान लगा सकते हैं।
आप क्या सीखेंगे:
- झरना और फुर्तीली मॉडल वर्कफ़्लोज़
- झरना मॉडल
- चंचल वर्कफ्लो
- फुर्तीली बनाम झरना मॉडल के बीच अंतर
- चंचल परीक्षण बनाम झरना परीक्षण के बीच अंतर
- निष्कर्ष
झरना और फुर्तीली मॉडल वर्कफ़्लोज़
सरल अंग्रेजी में, एजाइल का अर्थ है 'जल्दी और आसानी से आगे बढ़ने में सक्षम' और इसलिए इसका मतलब है कि जब यह आता है फुर्तीली विकास पद्धति ।
फुर्तीली परियोजना प्रबंधन की एक विधि है जिसे लगातार समीक्षा और योजनाओं के अनुकूलन के साथ कार्यों को छोटे खंडों में विभाजित किया जाता है।
इसी तरह, झरना शब्द खड़ी बूंदों की एक श्रृंखला के माध्यम से पानी के एक ऊर्ध्वाधर प्रवाह या पानी के प्रवाह को दर्शाता है। झरना मॉडल एक रैखिक अनुक्रमिक मॉडल है, जिसमें प्रगति आवश्यकता एकत्र करने, विश्लेषण, डिजाइन, विकास, परीक्षण, तैनाती और रखरखाव के चरणों के माध्यम से एक दिशा में प्रमुख रूप से बहती है।
यह चित्रण परियोजना प्रबंधन की अवधारणा पर लागू होता है जब यह आता है झरना मॉडल । यह परियोजना प्रबंधन की एक विधि है जिसे धारावाहिक चरणों और कार्य की एक निश्चित योजना द्वारा दर्शाया जाता है।
(छवि स्रोत )
वाटरफॉल वर्कफ़्लो और एजाइल वर्कफ़्लो पर चर्चा करने से पहले, आइए हम सॉफ्टवेयर डेवलपमेंट लाइफ साइकल परिभाषा और इसकी आवश्यकताओं पर एक नज़र डालें।
सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल क्या है?
यह सॉफ्टवेयर को व्यवस्थित रूप से विकसित करने के लिए कदम प्रक्रिया द्वारा एक कदम है। इसके लिए, हम विभिन्न कंपनियों में विभिन्न प्रकार के सॉफ़्टवेयर विकास जीवन चक्रों से चयन करते हैं। आवश्यकता के आधार पर, एक उपयुक्त जीवन चक्र चुना जाता है।
झरना मॉडल एसडीएलसी प्रकारों में से एक है और यह सॉफ्टवेयर विकसित करने की एक पुरानी प्रक्रिया है। फुर्तीली मॉडल नवीनतम और उन्नत है। चंचलता अन्य सॉफ्टवेयर विकास जीवन चक्र से ली गई है।
अन्य एसडीएलसी में सर्पिल मॉडल, वी और वी मॉडल, प्रोटोटाइप मॉडल शामिल हैं। व्यवसाय की आवश्यकता की आवश्यकता और अनुकूलता के आधार पर, हम सॉफ्टवेयर एप्लिकेशन को विकसित करने के लिए सर्वश्रेष्ठ मॉडल का चयन करेंगे।
(छवि स्रोत )
सॉफ्टवेयर विकास जीवन चक्र की आवश्यकता क्यों है?
परियोजना को संरचित तरीके से प्रबंधित करने के लिए एसडीएलसी की आवश्यकता होती है। यह एक निश्चित स्तर का नियंत्रण प्रदान करता है और टीम के सदस्यों की भूमिकाओं और जिम्मेदारियों को परिभाषित करता है। यह एसडीएलसी में प्रत्येक चरण के लिए गुंजाइश और समय सीमा प्रदान करता है।
यह कुछ हद तक उपयोगकर्ता सदस्यों की तरह है जो गुणवत्तापूर्ण उत्पाद विकसित करने और वितरित करने के लिए सभी चरणों का पालन करते हैं। यह टीम प्रबंधन को उद्देश्यों और आवश्यकताओं को परिभाषित और मूल्यांकन करने में मदद करता है। यह कार्यों को निर्धारित करने और आकलन करने में भी मदद करता है। यह ग्राहक और विकास टीम के बीच संचार लाइन बनाता है और उनमें से प्रत्येक के लिए भूमिकाएं और जिम्मेदारियां बनाता है।
सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल के प्रकार
आइए हम सॉफ्टवेयर विकास प्रक्रिया में उपयोग किए जाने वाले एसडीएलसी के प्रकारों का संक्षिप्त परिचय देखें।
(1) झरना मॉडल
जैसा कि पहले चर्चा की गई है, झरना मॉडल पहला पेश किया गया सॉफ्टवेयर विकास जीवन चक्र है। यह विकासशील सॉफ्टवेयर का अनुक्रमिक तरीका है। बहुत कम कंपनियां इस दृष्टिकोण का पालन करती हैं। जब परियोजना बहुत सरल है और आगे कोई आवश्यकता नहीं है, तो हम इस दृष्टिकोण का पालन करेंगे।
हम इस ट्यूटोरियल में वाटरफॉल मॉडल पर अधिक चर्चा करेंगे।
# 2) फुर्तीली मॉडल
फुर्तीली वर्कफ़्लो सॉफ़्टवेयर डेवलपमेंट प्रक्रिया का एक उन्नत दृष्टिकोण है, जिसका उपयोग अधिकांश कंपनियों में किया जाता है। फुर्तीली को स्प्रिंट-आधारित सॉफ्टवेयर विकास जीवन चक्र के रूप में परिभाषित किया गया है।
आगामी अनुभागों में, हम फुर्तीली वर्कफ़्लो पर अधिक चर्चा कर सकते हैं।
# 3) सर्पिल मॉडल
यह वृद्धिशील क्रम में आवश्यकता को विभाजित और जोड़कर सॉफ्टवेयर के निर्माण और परीक्षण का तरीका है। यह मॉडल उन परियोजनाओं में मदद करेगा जहां आवश्यकताएं बदलती रहती हैं। यह सर्पिल मॉडल पुनरावृत्त विकास प्रक्रिया और अनुक्रमिक रैखिक विकास प्रक्रिया का संयोजन है।
यह दृष्टिकोण हमें उत्पाद के वृद्धिशील रिलीज में अनुमति देगा। यहां, रिलीज के लिए सॉफ़्टवेयर के सभी मॉड्यूल के पूरा होने की प्रतीक्षा करना आवश्यक नहीं है।
रैखिक अनुक्रमिक मॉडल का मतलब है कि यह सॉफ्टवेयर विकास का एक व्यवस्थित अनुक्रमिक दृष्टिकोण है जो सिस्टम स्तर पर शुरू होता है और विश्लेषण, डिजाइन, कोडिंग, परीक्षण और समर्थन के माध्यम से आगे बढ़ता है।
पुनरावृत्त मॉडल का अर्थ है, यह एक सॉफ्टवेयर विकास जीवन चक्र का एक विशेष कार्यान्वयन है जो एक प्रारंभिक, सरलीकृत कार्यान्वयन पर केंद्रित है, जो तब उत्तरोत्तर अधिक जटिलता प्राप्त करता है और एक व्यापक सुविधा तब तक सेट होती है जब तक कि अंतिम प्रणाली पूरी नहीं हो जाती।
# 4) प्रोटोटाइप मॉडल
इस मॉडल में सॉफ़्टवेयर के निर्माण और परीक्षण की प्रक्रिया इस तरह से शामिल है कि, पहले हम डमी मॉडल विकसित करते हैं और यदि यह व्यवहार्य है और सभी व्यावसायिक आवश्यकताओं तक पहुँचता है तो हम वास्तविक कामकाजी मॉडल को लागू करते हैं।
यहां पहले, हमने प्रोटोटाइप का निर्माण और परीक्षण किया फिर सटीक सिस्टम विनिर्देशों के साथ वास्तविक मॉडल बनाया। सॉफ्टवेयर प्रोटोटाइप, सॉफ्टवेयर अनुप्रयोगों के प्रोटोटाइप बनाने की गतिविधि है।
# 5) वी और वी मॉडल
यह सत्यापन और सत्यापन मॉडल है। यहां, सॉफ़्टवेयर विकसित करते समय हम एसडीएलसी के प्रत्येक चरण में सब कुछ सत्यापित और सत्यापित करते थे। वी-मॉडल को जलप्रपात मॉडल का विस्तार माना जाता है।
तो, सभी एसडीएलसी प्रकारों में उनकी विशेषताएं और विशेषताएं हैं। परियोजना की आवश्यकता, आवश्यकताओं, व्यवहार्यता, समय अवधि के आधार पर, हम सॉफ्टवेयर एप्लिकेशन को विकसित करने के लिए विशेष सॉफ्टवेयर विकास जीवन चक्र चुन सकते हैं।
अब, हम जलप्रपात और फुर्तीली सॉफ्टवेयर विकास जीवन चक्रों पर विस्तार से चर्चा करेंगे।
झरना मॉडल
वॉटरफॉल मॉडल में, प्रत्येक चरण को दूसरे चरण को शुरू करने से पहले पूरा किया जाना चाहिए। हम एक ही समय में कई चरणों का संचालन नहीं कर सकते हैं। यह 1970 में विंस्टन रॉयस द्वारा पेश किया गया था। झरना मॉडल को विभिन्न चरणों में विभाजित किया गया है।
(छवि स्रोत )
जलप्रपात मॉडल में निम्नलिखित चरण शामिल हैं:
- आवश्यकता संग्रह
- व्यवहार्यता अध्ययन
- डिज़ाइन
- कोडन
- परिक्षण
- रखरखाव
(1) आवश्यकता विश्लेषण
यहां, व्यापार विश्लेषक को आवश्यकता विनिर्देश मिलेगा। आवश्यकता सीआरएस (ग्राहक आवश्यकता विनिर्देश) प्रारूप में होगी। सीआरएस बताता है कि व्यावसायिक प्रवाह को कैसे जाना चाहिए और निर्दिष्ट आवश्यकता के अनुसार आवेदन कैसे काम करना चाहिए। व्यापार विश्लेषक सीआरएस को एसआरएस (सॉफ्टवेयर रिक्वायरमेंट स्पेसिफिकेशन) में बदल देंगे।
फिर व्यापार विश्लेषक विकास और परीक्षण टीम के साथ आवश्यकता विनिर्देशों पर विस्तार से चर्चा करता है और विकास और परीक्षण के दृष्टिकोण से आवश्यकता को समझता है। वास्तविक आवश्यकताओं के आधार पर एप्लिकेशन सॉफ़्टवेयर बनाने के लिए आवश्यकताओं पर चर्चा और विश्लेषण करने का यह चरण है।
यहां, सॉफ़्टवेयर आवश्यकता विनिर्देश दस्तावेज़ में सब कुछ प्रलेखित किया जाना चाहिए। जलप्रपात मॉडल में, प्रत्येक चरण के सुपुर्दगी / परिणाम / आउटपुट अगले चरणों के लिए इनपुट स्रोत है।
सेवा-आधारित उद्योग में, एक व्यापार विश्लेषक आवश्यकता ला सकता है।
उत्पाद-आधारित कंपनी में, उत्पाद विश्लेषक आवश्यकता लाता है।
# 2) व्यवहार्यता अध्ययन
प्रबंधन टीम व्यवहार्यता अध्ययन करेगी। इसका मतलब है, टीम मानकों का विश्लेषण करेगी, क्या यह आवश्यकता है / आवेदन हमारे वातावरण में विकसित किया जा सकता है या नहीं, उपलब्ध संसाधन पर्याप्त है या नहीं, लागत और कई अन्य कारक संभव हैं या नहीं और जाँच करने के लिए हम कवर करने में सक्षम हैं या नहीं सभी व्यापार प्रवाह या नहीं।
इस बैठक / विश्लेषण में, प्रोजेक्ट मैनेजर, बिजनेस एनालिस्ट, फाइनेंस मैनेजर, एचआर, प्रोजेक्ट लीड चर्चा का हिस्सा होंगे।
# 3) सिस्टम डिज़ाइन
यहां, प्रोजेक्ट आर्किटेक्ट सिस्टम डिजाइन तैयार करेगा। वह हार्डवेयर, सिस्टम की आवश्यकता को निर्दिष्ट करेगा और एप्लिकेशन आर्किटेक्चर को डिजाइन करेगा। सिस्टम डिज़ाइन में 2 भाग होते हैं: उच्च-स्तरीय डिज़ाइन और निम्न-स्तरीय डिज़ाइन। उच्च-स्तरीय डिज़ाइन में, हम एप्लिकेशन के विभिन्न ब्लॉकों को डिज़ाइन करते हैं। निम्न-स्तरीय डिज़ाइन में, हम छद्म कोड लिखते हैं।
# 4) कोडिंग
यहां, डेवलपर्स विभिन्न तरीकों और विभिन्न लॉजिक्स का उपयोग करके एप्लिकेशन के प्रत्येक फ़ंक्शन और UI का सटीक कोडिंग शुरू करते हैं। वे एप्लिकेशन बनाने के लिए किसी भी प्रोग्रामिंग भाषा जैसे जावा, पायथन या किसी अन्य भाषा का उपयोग कर सकते हैं।
एक बार कोडिंग आवेदन के विशेष मॉड्यूल की प्रत्येक कार्यक्षमता के लिए पूरा हो जाने पर, डेवलपर इकाई परीक्षण करेगा। यदि कोड ठीक काम करता है, तो डेवलपर कोड को परीक्षण वातावरण में तैनात करेगा और परीक्षण के लिए परीक्षक को बिल्ड देगा।
# 5) परीक्षण
यहां से परीक्षण गतिविधि शुरू होती है। इस चरण तक, हमें झरना मॉडल में कोई काम नहीं होगा। इस चरण में, हम सभी प्रकार के परीक्षण करते हैं। इन परीक्षण प्रकारों में धूम्रपान परीक्षण, कार्यात्मक परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण, स्वीकृति परीक्षण, प्रतिगमन परीक्षण, तदर्थ परीक्षण, खोजपूर्ण परीक्षण और क्रॉस-ब्राउज़र परीक्षण शामिल हैं।
बिल्ड मिलते ही हम एप्लिकेशन का परीक्षण शुरू कर देंगे। सबसे पहले, हम धूम्रपान परीक्षण के साथ शुरू करेंगे। यदि कोई अवरोधक मुद्दे नहीं देखे जाते हैं, तो हम विस्तार से परीक्षण जारी रखेंगे।
कार्यात्मक परीक्षण में, हम आवेदन के प्रत्येक घटक का परीक्षण करना शुरू करेंगे। यहां हम टेक्स्ट फ़ील्ड, बटन, लिंक, रेडियो बटन, अपलोड बटन, ड्रॉपडाउन और नेविगेशन लिंक जैसे विभिन्न घटकों की जांच करते हैं।
अगला, हम यूआई की जांच करेंगे, देखो और महसूस करेंगे और सकारात्मक और नकारात्मक इनपुट परीक्षण करेंगे।
फिर हम एकीकरण परीक्षण के साथ शुरू करेंगे। यहां हम डेटा एकीकरण की जांच करेंगे। हम यह सत्यापित करेंगे कि क्या एक ही डेटा विभिन्न संबंधित पृष्ठों में परिलक्षित हो रहा है या नहीं, संबंधित पृष्ठों पर ईमेल लिंक नेविगेशन सत्यापित करेगा। हम तृतीय पक्ष एप्लिकेशन के साथ डेटा एकीकरण की जांच करेंगे और एप्लिकेशन में डेटाबेस परिवर्तन की जांच करेंगे।
अगला, हम सिस्टम परीक्षण करेंगे। हम पूरे आवेदन की जाँच एक इकाई के रूप में करेंगे। हम कार्यक्षमता, पृष्ठों के एकीकरण, क्षेत्र सत्यापन, त्रुटि संदेश, पुष्टिकरण संदेश और कई और अधिक की जांच करेंगे।
एप्लिकेशन का परीक्षण करते समय हम बग ट्रैकिंग टूल में मुद्दों को लॉग करेंगे। हम मुद्दों के आधार पर बग के लिए प्राथमिकता देंगे। बग को बनाने के बाद हम संबंधित डेवलपर को समस्या को ठीक करने के लिए असाइन करेंगे। डेवलपर्स द्वारा उन्हें ठीक करने के बाद डेवलपर्स को असाइन करने के बाद हम बग को सत्यापित करेंगे। यदि यह ठीक काम करता है तो परीक्षक बग को बंद कर देगा, और अन्य परीक्षक समस्या को ठीक करने के लिए डेवलपर को वापस असाइन करेंगे। यह बग जीवन चक्र कैसे चलता है।
फिर हम स्वीकृति परीक्षण के लिए आगे बढ़ते हैं। यहां हम स्टेजिंग और यूएटी (उपयोगकर्ता स्वीकृति परीक्षण) जैसे विभिन्न वातावरणों में एप्लिकेशन का परीक्षण करते हैं। कोड को उत्पादन वातावरण में ले जाने से पहले आवेदन को अच्छी तरह से जांचने के लिए यह सबसे महत्वपूर्ण चरण है।
एक बार जब स्वीकृति परीक्षण बिना किसी त्रुटि के किया जाता है, तो ग्राहक उत्पादन सर्वर पर कोड को तैनात करने और रिहाई की योजना बनाएगा।
# 6) रखरखाव
एक बार जब हम एप्लिकेशन कोड को उत्पादन सर्वर पर तैनात करते हैं, तो हमें क्लाइंट एप्लिकेशन को समर्थन / रखरखाव प्रदान करना चाहिए। यह रखरखाव चरण वास्तविक समय के उत्पादन के मुद्दों को देखने और ठीक करने के लिए है, मेमोरी मुद्दों की जांच करने के लिए, एप्लिकेशन को बढ़ाने के लिए, और नए आवश्यकता परिवर्तनों को विकसित करने के लिए।
किन मामलों में हम वाटरफॉल मॉडल का विकल्प चुन सकते हैं?
- जब कोई आवश्यक परिवर्तन नहीं हैं।
- जब प्रोजेक्ट छोटा और सरल हो।
- जब तकनीक में कोई जटिलता नहीं है।
- जब अधिक संसाधन उपलब्ध हों।
झरना पेशेवरों:
- आगे पीछे योजना और कार्यान्वयन आसान है ।
- झरना मॉडल का उपयोग करने के लिए सरल और समझने में आसान है। यह परियोजना प्रबंधकों या कर्मचारियों के लिए किसी विशेष प्रशिक्षण की आवश्यकता नहीं है। यह एक है आसान सीखने की अवस्था ।
- प्रकृति में कठोर होना, यह है प्रबंधन करने में आसान झरना चक्र। प्रत्येक चरण में डिलिवरेबल्स और एक समीक्षा प्रक्रिया निर्धारित की गई है।
- कम जटिलता जैसा कि चरण ओवरलैप नहीं होते हैं। एक के बाद एक चरणों का पालन किया जाता है। यह अन्य सॉफ़्टवेयर डेवलपमेंट मेथडॉलॉजी की तुलना में स्पष्ट संरचना का उपयोग करता है। यह परियोजना निर्धारित क्रमिक चरणों से गुजरती है, जो आवश्यकता के अनुसार शुरू होती है और अंत में रखरखाव पर आधारित होती है।
- चरणबद्ध विकास के कारण, अनुशासन लागू किया जाता है , और timescales आसानी से रखा जा सकता है।
- काम करता है छोटी परियोजनाओं के लिए अच्छी तरह से जहां हमारे पास निश्चित और क्रिस्टल-स्पष्ट आवश्यकताएं हैं।
- प्रक्रियाएं और परिणाम हैं अच्छी तरह से प्रलेखित ।
- कार्यों को व्यवस्थित करना आसान है।
- यह है प्रगति को मापना आसान है प्रत्येक चरण की शुरुआत और समापन बिंदु पूर्व निर्धारित हैं।
- पूरे प्रोजेक्ट में आवश्यकताओं में लगभग कोई बदलाव नहीं है, इसलिए कार्य स्थिर रहते हैं डेवलपर्स के लिए। साथ ही, यह किसी के लिए भी आसान है नए डेवलपर जल्दी से जानने के लिए और काम शुरू करो।
- वहां कोई वित्तीय आश्चर्य नहीं । एक बार आवश्यकताओं को तय करने के बाद, विकास शुरू करने से पहले अंतिम लागत की गणना की जा सकती है।
- एक के लिए पूरा करता है अनुक्रमिक वित्त पोषण मॉडल ।
- आईटी इस विस्तृत डिजाइन अंतिम अपेक्षित परिणाम सभी के लिए बहुत स्पष्ट है।
- आवश्यकता एकत्रित चरण में प्रलेखित कार्यात्मक आवश्यकता विनिर्देश परीक्षकों को परीक्षण परिदृश्यों और परीक्षण मामलों को डिजाइन करने के लिए पर्याप्त विवरण देता है। इसलिए परीक्षण प्रक्रिया आसान हो जाती है झरना मॉडल में।
झरना विपक्ष:
- जैसा कि विकास शुरू करने से पहले सभी आवश्यकताओं को स्पष्ट रूप से जाना जाना चाहिए, यह परियोजना में देरी करता है ।
- व्यापक शोध की आवश्यकता है उपयोगकर्ता की जरूरतों में।
- परियोजना के शुरुआती चरण में, ग्राहक के लिए कार्यात्मक विशिष्टताओं के रूप में उनकी आवश्यकताओं को स्पष्ट रूप से परिभाषित करना और उनकी अवधारणा को समझना चुनौतीपूर्ण है। इसलिए, अंतिम उत्पाद को देखने के बाद उनके मन को बदलने की संभावना है। यह परिवर्तन व्यवसाय योजना या बाजार प्रभाव के कारण भी हो सकता है। इस मॉडल में कम लचीलापन इसे बनाता है ऐसे किसी भी बदलाव को समायोजित करना मुश्किल है , खासकर जब उत्पाद को काफी हद तक फिर से इंजीनियर करने की आवश्यकता होती है।
- कोई कामकाजी मॉडल नहीं तक उत्पादन किया जाता है बाद में झरना जीवन चक्र के दौरान मंच।
- धीमे प्रसव के समय । ग्राहक पूरी तरह से पूरा होने तक उत्पाद को देखने में सक्षम नहीं होता है।
- ग्राहक के पास पहले से सिस्टम से परिचित होने का कोई अवसर नहीं है। झरना मॉडल अधिक है आंतरिक प्रक्रियाएं तथा अंत-उपयोगकर्ता को बाहर रखा गया है ।
- ग्राहक को सूचित नहीं किया जाता है परियोजना के स्वास्थ्य के बारे में अच्छी तरह से।
- डेडलाइन छूट सकती है यदि सख्त प्रबंधन और नियमित निगरानी नहीं रखी जाती है।
- वहाँ है बदलाव के लिए कोई जगह नहीं है भले ही यह विकास के दौरान दिखाई देता हो, क्योंकि उत्पाद बाजार की आवश्यकता को पूरा करने वाला नहीं है।
- परीक्षण में देरी करता है पूरा होने तक। इसके अलावा, बड़े संशोधन इस बिंदु पर बहुत महंगे हैं।
- उच्च जोखिम और अनिश्चितता झरने के मॉडल में शामिल हैं क्योंकि मुद्दों के लिए बहुत ज्यादा जगह नहीं है जब तक कि परियोजना पूरी होने के करीब नहीं आती।
- उपयुक्त मॉडल नहीं है लंबी, जटिल और चल रही परियोजनाओं के लिए।
- ऐसा करना कठिन है प्रगति को मापें प्रत्येक चरण के भीतर।
- परियोजना के कई चरणों के दौरान परीक्षक बेकार बैठेंगे।
चंचल वर्कफ्लो
अब हम एजाइल सॉफ्टवेयर विकास जीवन चक्र देखेंगे। फुर्तीली अधिक सटीकता के साथ जल्दी और आसानी से काम करने की प्रक्रिया है।
यह मॉडल परियोजना प्रबंधन की एक विधि से संबंधित है, जिसका उपयोग विशेष रूप से सॉफ्टवेयर विकास के लिए किया जाता है। यह कार्य के छोटे चरणों में कार्यों के विभाजन और लगातार पुनर्मूल्यांकन और योजनाओं के अनुकूलन की विशेषता है। प्रत्येक टीम के सदस्य को मूल व्यवसाय प्रवाह का विचार होना चाहिए।
(छवि स्रोत )
एजाइल में, डेवलपर्स और परीक्षक एप्लिकेशन सॉफ़्टवेयर को विकसित करने और परीक्षण करने के लिए समानांतर रूप से काम करते हैं। विकास पुनरावृत्त मोड में किया जाता है। प्रत्येक पुनरावृत्ति उपयोगकर्ता कहानियों को विश्लेषण, डिजाइन, कोडिंग और परीक्षण की आवश्यकता होती है।
हम यह सत्यापित करने के लिए कि आवश्यकता त्रुटि-मुक्त है और कार्यान्वयन योग्य है या नहीं, विस्तृत रूप से आवश्यकता का परीक्षण करते हैं। प्रत्येक पुनरावृत्ति की समाप्ति के बाद अगली पुनरावृत्ति पर स्विच करें और हम नई / अन्य आवश्यकताओं के लिए एक ही प्रक्रिया का पालन करते हैं।
इस प्रकार, सॉफ्टवेयर के ब्लॉक के विकास और परीक्षण की यह प्रक्रिया कम समय में अधिक सटीकता और लचीलेपन के साथ की जाती है। इसलिए अधिक उद्योग इस प्रक्रिया का पालन करते हैं और अपनाते हैं।
सबसे पहले, उत्पाद स्वामी उत्पाद बैकलॉग में सभी आवश्यकताओं को जोड़ देगा। उत्पाद बैकलॉग में सभी उपयोगकर्ता कहानियां हैं। बता दें, 100 से 150 यूजर स्टोरी पूरी परियोजना से संबंधित हैं। अब स्प्रिंट बैकलॉग में उन विशेष उपयोगकर्ता कहानियों को जोड़ें जिन्हें हमें लागू करने की आवश्यकता है। फिर, सभी डेवलपर्स, क्यूए, बीए स्प्रिंट आइटम पर काम करेंगे। यह कैसे फुर्तीली प्रवाह काम करता है।
चुस्त में प्रयुक्त प्रमुख शब्दावली
स्प्रिंट बैकलॉग क्या है?
क्रोम पर swf फ़ाइल कैसे खोलें
यह उपयोगकर्ता कहानियों की सूची है जिसे हमें वर्तमान पुनरावृत्ति या स्प्रिंट में लागू करने की आवश्यकता है।
उदाहरण के लिए, स्प्रिंट बैकलॉग में 20 से 30 उपयोगकर्ता कहानियां हैं। फिर ये उपयोगकर्ता कहानियां हैं जिन्हें हमें वर्तमान स्प्रिंट में लागू करने की आवश्यकता है।
(छवि स्रोत )
स्प्रिंट क्या है?
स्प्रिंट एक छोटी अवधि है जिसमें हमें किसी विशेष अवधि के भीतर चयनित उपयोगकर्ता कहानियों को लागू करने की आवश्यकता होती है। स्प्रिंट की अवधि लगभग 2 से 3 सप्ताह होगी। इसकी अवधि कंपनी से कंपनी में भिन्न होती है।
इस स्प्रिंट अवधि में, टीम को आवश्यकता का विश्लेषण करना है, आवश्यकताओं को डिज़ाइन करना है, कोडिंग, परीक्षण करना, समस्या को ठीक करना, पुन: परीक्षण, प्रतिगमन परीक्षण, डेमो, और कई और गतिविधियाँ करना है।
डेली स्टैंडअप स्क्रेम मीटिंग
व्यवसाय विश्लेषक, डेवलपर, परीक्षक, परियोजना प्रबंधक दैनिक स्टैंड अप स्क्रैम मीटिंग्स का हिस्सा हैं। यह दैनिक रूप से किया जाता है। इसे 15 से 30 मिनट से अधिक नहीं बढ़ाया जाना चाहिए।
यहां टीम के सभी सदस्य दैनिक कार्य की स्थिति साझा करेंगे। जिन मुख्य बातों पर हम यहाँ चर्चा करते हैं, वे हैं: कल पूरी हुई चीज़ें, आज के काम की योजना, और कोई भी चुनौती या निर्भरता जो वे परियोजना में झेल रहे हैं।
यदि कोई भी टीम सदस्य परियोजना के दौरान किसी भी चुनौती या बाधाओं का सामना करता है, तो संबंधित व्यक्ति उस पर काम करेगा।
कार्य समय चार्ट
यह समय और काम का एक चित्रमय ग्राफ प्रतिनिधित्व है। एक्स-एक्सिस शेष कार्य का प्रतिनिधित्व करता है, वाई-अक्ष बचे हुए स्प्रिंट समय का प्रतिनिधित्व करता है। टीम को विशेष स्प्रिंट में उपलब्ध समय से संबंधित कार्य कार्यों को बनाना होगा। टीम ने जो काम किया है और पूरा किया है उसके आधार पर दैनिक आधार पर कार्य के घंटे जलाएंगे।
(छवि स्रोत )
कानबन चार्ट
यह एक परियोजना प्रबंधन चार्ट / उपकरण है। इसके साथ, हम पूरे प्रोजेक्ट के कार्यों का प्रबंधन कर सकते हैं। हम परियोजना की प्रगति की स्थिति और व्यक्तियों के काम की स्थिति की जांच कर सकते हैं। यह प्रगति की वस्तुओं, लंबित वस्तुओं, तैयार वस्तुओं के सचित्र डिजिटल प्रतिनिधित्व को दर्शाता है।
(छवि स्रोत )
विंडोज़ में json फ़ाइल कैसे खोलें
योजना पोकर गतिविधि
यह स्प्रिंट टीम के सदस्यों के बीच उपयोगकर्ता कहानियों का अनुमान लगाने के लिए एक खेल है। यहां पूरी टीम पोकर एक्टिविटी खेलेगी। प्रत्येक टीम के सदस्य उपयोगकर्ता कहानी बिंदु के आधार पर अनुमान देते हैं। बहुमत के अनुमान के आधार पर, टीम समय स्लॉट को तय करेगी और आवंटित करेगी।
उदाहरण के लिए , एक उपयोगकर्ता कहानी टीम के सदस्य 3, 5, 8, 3, 1, 3 जैसे अनुमान देगा। फिर टीम अनुमान के रूप में 3 का चयन करेगी। पोकर गतिविधि कार्ड में 0, 1, 3, 5, 8, 13, 20, 100, ब्रेक, संदेह शामिल हैं? पत्ते। इसके आधार पर टीम के सदस्य किसी भी अनुमान कार्ड का सुझाव देंगे। इस तरह, हम उन सभी उपयोगकर्ता कहानियों का अनुमान लगाएंगे जो विशेष स्प्रिंट से संबंधित हैं।
(छवि स्रोत )
- 0 पोकर संख्या का प्रतिनिधित्व करता है: उस आइटम / उपयोगकर्ता कहानी में कोई कार्य नहीं
- 1, 3 नंबर दर्शाते हैं: कार्य कम है
- 5, 8 संख्याएँ दर्शाती हैं: मध्यम स्तर के कार्य
- 13, 20 संख्या का प्रतिनिधित्व करता है: बड़े स्तर के कार्य
- 100 नंबर का प्रतिनिधित्व करता है: बहुत बड़े कार्य
- अनंत का प्रतिनिधित्व करता है: टास्क विशाल है, कई कार्यों और उपयोगकर्ता कहानियों में विभाजित करने की आवश्यकता है
- ब्रेक का प्रतिनिधित्व करता है: एक विराम चाहिए
- ? प्रस्तुतकर्ता: संदेह
जमघट मास्टर
वह वह व्यक्ति है जो टीम को फुर्तीली प्रक्रिया का पालन करने और परियोजना की आवश्यकता को पूरा करने में मदद करता है। जब भी आवश्यकता होगी वह बैठक आयोजित करेगा और परियोजना की आवश्यकता पर चर्चा करने में मदद करेगा।
स्क्रैम मास्टर चुनौतियों को हल करने के लिए सभी टीम के सदस्यों के लिए एक सेतु के रूप में कार्य करता है और इस परियोजना पर निर्भरताएँ। वह प्रत्येक स्प्रिंट के विषय में परियोजना की प्रगति को ट्रैक करेगा।
वह स्टैंडअप मीटिंग, पूर्वव्यापी बैठक, निरीक्षण, समीक्षा, डेमो में शामिल है। वह वह है जो रोजाना स्टैंड अप मीटिंग आयोजित करता है और टीम मेंबर अपडेट लेता है।
उत्पाद स्वामी
वह वह व्यक्ति है जो व्यावसायिक दृष्टिकोण से उत्पाद / परियोजना को चलाता है और उसकी निगरानी करता है। वह यह देखता रहता है कि उत्पाद को व्यवसाय की आवश्यकता के अनुसार विकसित किया गया है या नहीं। वह वह है जो उपयोगकर्ता कहानियों को प्राथमिकता देता है और उत्पाद बैकलॉग से स्प्रिंट बैकलॉग की आवश्यकताओं को स्थानांतरित करता है। वह परियोजना की समय सीमा का अनुमान लगाएंगे।
वह हमेशा उपयोगकर्ता के दृष्टिकोण से उत्पाद को देखता है। उत्पाद स्वामी को इस बारे में पूरी जानकारी है कि आवेदन कैसे काम करना चाहिए।
प्रयोक्ता कहानी
यह आवश्यकता का एक ब्लॉक है। इसमें उपयोग मामलों / आवश्यकता का सेट होता है जो एक ही मॉड्यूल से संबंधित होता है। यहां हम परिभाषित करते हैं कि किसी एप्लिकेशन के प्रत्येक घटक को कैसे काम करना चाहिए और UI को कैसे दिखना चाहिए। प्रत्येक घटक का दायरा उपयोगकर्ता कहानी में परिभाषित किया गया है।
कार्य
टीम के सदस्य उपयोगकर्ता कहानी के लिए कार्य बनाने जा रहे हैं जो उन्हें सौंपा गया है। उन्हें विकास कार्य, परीक्षण कार्य, उपयोगकर्ता कहानी विश्लेषण कार्य जैसे विभिन्न कार्यों के आधार पर कार्य बनाने की आवश्यकता है। टास्क अवधि उपयोगकर्ता कहानी बिंदुओं पर निर्भर होनी चाहिए।
एक परीक्षक के रूप में, हम उपयोगकर्ता कहानी विश्लेषण, परीक्षण मामले की तैयारी, निष्पादन, प्रतिगमन परीक्षण, और कई और अधिक के लिए कार्य बनाएंगे।
बैकलॉग संवारना
इस भाग में बैकलॉग आइटम का प्रबंधन शामिल है। यहां हम जो गतिविधियां करते हैं, वह बैकलॉग आइटम्स को प्राथमिकता देना, छोटी वस्तुओं को तोड़ना, कार्य बनाना और स्वीकृति मानदंडों को अद्यतन करना है।
यात्रा
Iteration सॉफ्टवेयर अनुप्रयोग के कुछ मॉड्यूल / भागों का विकास और परीक्षण है। प्रत्येक पुनरावृत्ति में उत्पाद का विश्लेषण होता है, उत्पाद का डिजाइन, उत्पाद का विकास, उत्पाद का परीक्षण, और उत्पाद का डेमो होता है।
चुस्त कार्यप्रणाली अपनाने के लिए महत्वपूर्ण कारक
- अवलोकन: नियमित रूप से काम और उत्पाद की समीक्षा करें और तदनुसार गतिविधियों की योजना बनाएं। इसलिए उत्पाद विकास प्रक्रिया और उत्पाद की गुणवत्ता अच्छी होगी।
- आपका स्वागत है परिवर्तन: परिवर्तन बहुत आसानी से संभाला जाता है। यह उत्पाद पर बहुत अधिक प्रभावित नहीं करता है क्योंकि सॉफ़्टवेयर के मॉड्यूल अलग-अलग विकसित होते हैं और बाद में एकीकृत होते हैं। इसलिए, यदि भविष्य में आवश्यकता बदल गई तो कोई पुनरावृत्ति नहीं होगी।
- समय सीमा: हमें आवेदन की प्रत्येक इकाई के लिए समय सीमा दी गई है। तो अनुमान परियोजना समय के अनुमानों के प्रति सटीक होगा।
- ग्राहक संतुष्टि: ग्राहक की संतुष्टि अधिक है क्योंकि हम पूरे प्रोजेक्ट में क्लाइंट और स्टॉकहोल्डर के साथ बातचीत करते हैं और हम उत्पाद विकास के प्रत्येक स्तर पर एक डेमो देंगे। इसके द्वारा, हम व्यापार प्रवाह और कार्य प्रगति के बारे में नियमित रूप से ग्राहक / ग्राहक प्रतिक्रिया प्राप्त करते हैं। इस प्रकार आवेदन का कार्य और विकास उसी के अनुसार किया जाता है।
चुस्त तरीके के प्रकार
- चंचल स्क्रम पद्धति
- लीन सॉफ्टवेयर डेवलपमेंट
- Kanban
- चरम प्रोग्रामिंग (XP)
- क्रिस्टल
- डायनेमिक सिस्टम डेवलपमेंट मेथड (DSDM)
- फ़ीचर ड्रिवेन डेवलपमेंट (FDD)
चंचल पेशेवरों:
- फुर्तीली मॉडल का एक सबसे बड़ा फायदा है महान अनुकूलनशीलता । अनुकूलनशीलता का अर्थ है 'परिवर्तन का जवाब'। ग्राहक की जरूरतों और प्राथमिकताओं में बदलाव से निपटने में एजाइल बहुत लचीला है।
- की अनुमति देता है लगातार परिष्कृत करें और समग्र उत्पाद बैकलॉग को फिर से प्राथमिकता दें वर्तमान पुनरावृत्ति को प्रभावित किए बिना जिसमें टीम MVP को वितरित करने पर केंद्रित है। परिवर्तनों को अगले पुनरावृत्ति के लिए नियोजित किया जा सकता है, जिससे कुछ ही हफ्तों में बदलाव लाने का अवसर मिलता है।
- चंचल कार्यप्रणाली के एक महान डिग्री प्रदान करता है हितधारकों की वचनबद्धता । क्लाइंट और प्रोजेक्ट टीम प्रत्येक स्प्रिंट से पहले, दौरान और उसके बाद मिलते हैं। चूंकि ग्राहक पूरे प्रोजेक्ट में लगातार शामिल होता है, इसलिए टीम के पास ग्राहक के विज़न को स्पष्ट रूप से समझने के लिए अधिक अवसर होते हैं।
- काम करने वाला सॉफ्टवेयर जल्दी और अक्सर दिया जाता है। इससे वृद्धि होती है हितधारक का विश्वास टीम में और टीम को प्रोत्साहित करती है अत्यधिक प्रतिबद्ध रहें परियोजना के लिए।
- यह मॉडल देता है पारदर्शिता । दोनों हितधारकों और टीम को अच्छी तरह से पता है कि क्या हो रहा है। ग्राहक कार्य को प्रगति पर देख सकता है।
- एक से चार सप्ताह की निश्चित अनुसूची स्प्रिंट जल्दी और उम्मीद के मुताबिक वितरण । नई सुविधाओं को समय-समय पर तरीके से जल्दी और अक्सर जारी किया जाता है।
- चंचल है ग्राहक केंद्रित । यह न केवल कार्यक्षमता प्रदान करता है, बल्कि उस विशेषता को भी वितरित करने पर केंद्रित है जो उपयोगकर्ता के लिए कुछ मूल्य है। प्रत्येक उपयोगकर्ता कहानी में एक व्यवसाय-केंद्रित स्वीकृति मानदंड है।
- मूल्यवान उपभोक्ता की राय प्राप्त होता है शीघ्र परियोजना में और उत्पाद में परिवर्तन आवश्यकतानुसार किए जा सकते हैं।
- ध्यान व्यावसायिक मूल्य पर है । यह पहले क्लाइंट के लिए सबसे महत्वपूर्ण है जो बचाता है।
- डिलिवरेबल्स की गुणवत्ता में सुधार करता है । झरना के विपरीत, परीक्षण लगातार और अक्सर एक फुर्तीली परियोजना में किया जाता है और बदले में, मुद्दों का जल्द पता लगाने और ठीक करने में मदद करता है।
- चुस्त TDD (टेस्ट ड्रिवेन डेवलपमेंट) दृष्टिकोण का समर्थन करता है एमवीपी के माध्यम से जारी होने वाली सुविधाओं के लिए इकाई परीक्षण बनाने के लिए पर्याप्त समय प्रदान करता है।
- उत्पादन करके भी लगातार बनाता है , ग्राहकों की आवश्यकताओं के साथ किसी भी मिसलिग्न्मेंट का भी पता लगाया जा सकता है और जल्दी तय किया जा सकता है।
- जैसा हमें मिलता है तत्काल उपयोगकर्ता प्रतिक्रिया प्रत्येक एमवीपी रिलीज के बाद, परियोजना की विफलता का जोखिम कम है, जब आप चुस्त तरीके से काम कर रहे हैं।
- चुस्त टीम वर्क को बढ़ावा देता है । चंचल टीम के सदस्यों के बीच एक महान सहयोग, संपर्क, सद्भाव और उत्साह है।
- स्प्रिंट की शुरुआत से पहले ग्राहक को प्रत्येक स्प्रिंट की लागत और अनुसूची अनुमानों को सूचित किया जाता है। इस निर्णय लेने में सुधार करता है जैसा कि उपयोगकर्ता प्रत्येक सुविधा की लागत को समझ सकता है और तदनुसार प्राथमिकता दे सकता है।
- एक फुर्तीली परियोजना में, के लिए जगह है निरंतर सुधार । पिछले स्प्रिंट से सीखे गए सबक आगामी स्प्रिंट में लागू किए जा सकते हैं।
- यह परियोजना के प्रत्येक चरण में विशेष कार्य पर केंद्रित है।
चंचल विपक्ष:
- अक्सर यह देखा जाता है कि एजाइल टीमों में ए उपेक्षा प्रलेखन की प्रवृत्ति । यह इसलिए है क्योंकि एजाइल घोषणापत्र व्यापक प्रलेखन की तुलना में काम करने वाले सॉफ्टवेयर पर अधिक ध्यान केंद्रित करता है। हालांकि, टीमों को कोड और प्रलेखन के बीच सही संतुलन बनाए रखना चाहिए।
- चूँकि इसके लिए उच्च स्तर की ग्राहक भागीदारी की आवश्यकता होती है कभी-कभी ग्राहकों के लिए समस्याग्रस्त हो सकते हैं जिनके पास परियोजना में भाग लेने के लिए ज्यादा समय और रुचि नहीं है।
- अगर टीम में प्रतिबद्धता और समर्पण की कमी है तो यह अच्छी तरह से काम नहीं करता है। झरना को भागीदारी की आवश्यकता होती है, हालांकि, एजाइल को प्रतिबद्धता की आवश्यकता होती है।
- यदि प्रारंभिक वास्तुकला और डिजाइन कमजोर हैं, तो लगातार परावर्तन आवश्यक है।
- जब झरने से तुलना की जाती है, तो एजाइल है अभ्यास करना कठिन है । टीम के सदस्यों को फुर्तीली अवधारणाओं में पारंगत होना चाहिए। एजाइल का अभ्यास करने के लिए बहुत अनुशासन और प्रतिबद्धता की आवश्यकता होती है।
- पुन: प्राथमिकता के कारण, यह है कम अनुमानित है स्प्रिंट के अंत में क्या दिया जाएगा।
- समय-समय पर वितरण और लगातार पुन: प्राथमिकता के कारण, कुछ सुविधाओं के लिए आवंटित समयरेखा में वितरित नहीं होने की संभावना है। यह करने के लिए नेतृत्व कर सकते हैं अतिरिक्त स्प्रिंट और अतिरिक्त लागत । इसके कारण भी समस्या हो सकती है नेबुला समयसीमा ।
- झरने की तुलना में संरचना का अभाव, यह स्व-अनुशासित, अत्यधिक कुशल और क्रॉस-कुशल टीमों की मांग करता है । इसके बिना, परियोजना वास्तव में एक चुनौतीपूर्ण हो सकती है।
- उपलब्धता है अंतिम सुपुर्दगी का खाका कम ।
- कभी - कभी बाहरी हितधारक निम्नलिखित एगाइल दृष्टिकोण का विरोध नहीं कर सकते हैं । ऐसे मामलों में, विस्तृत दर्शकों के लिए एजाइल के बारे में प्रशिक्षण और शिक्षा की आवश्यकता होती है।
- टीम के सभी सदस्यों को परियोजना के प्रबंधन में शामिल होना आवश्यक है।
- प्रलेखन कम विस्तृत है।
फुर्तीली बनाम झरना मॉडल के बीच अंतर
झरना और फुर्तीली सॉफ्टवेयर विकास जीवन चक्र के बीच अंतर नीचे सूचीबद्ध हैं।
| झरना | चुस्त |
|---|---|
| इस प्रक्रिया को एक एकल परियोजना के रूप में माना जाता है जिसे आगे विभिन्न चरणों में विभाजित किया गया है। | प्रक्रिया को कई परियोजनाओं में विभाजित किया गया है और प्रत्येक परियोजना में विभिन्न चरणों की पुनरावृत्ति है। |
| जलप्रपात कार्यप्रणाली एक ऐसा मॉडल है जिसमें उत्पाद के जीवनचक्र का प्रत्येक चरण एक क्रम में होता है। झरने के सदृश इन चरणों के माध्यम से परियोजना की प्रगति धीरे-धीरे नीचे की ओर बहती है। | चंचल कार्यप्रणाली एक मॉडल है जो एक पुनरावृत्त दृष्टिकोण का अनुसरण करता है। |
| यह मॉडल एक बार के बड़े पैमाने पर पूरे वितरण में विश्वास करता है। उत्पाद को SDLC के अंत में वितरित किया जाता है। | यह मॉडल परिभाषित समय अंतराल पर वितरण के कई छोटे विखंडों में विश्वास करता है। प्रत्येक स्प्रिंट के अंत में एक एमवीपी (न्यूनतम व्यवहार्य उत्पाद) दिया जाता है। |
| इसका पारंपरिक और पुराने ढंग का दृष्टिकोण है। | इसका एक नया और आधुनिक तरीका है। |
| एक एकल चक्र और एक रिलीज। | पुनरावृत्तियों की पुनरावृत्ति संख्या और कई रिलीज़। |
| यह सॉफ्टवेयर विकास जीवनचक्र को विभिन्न चरणों में विभाजित करता है। | यह सॉफ्टवेयर विकास जीवनचक्र को स्प्रिंट में विभाजित करता है। |
 |  |
| संरचित और कठोर मॉडल। परियोजना के विवरण, विनिर्देश और डिजाइन को बदलना मुश्किल है। | यह मॉडल अपने लचीलेपन के लिए जाना जाता है। हम किसी भी समय किसी भी परियोजना के चरण में परिवर्तन कर सकते हैं। |
| दीर्घकालिक योजना पैमाने। | शॉर्ट टर्म प्लानिंग स्केल। |
| ग्राहक और डेवलपर के बीच एक लंबी दूरी मौजूद है। | ग्राहक और डेवलपर के बीच थोड़ी दूरी मौजूद है। |
| विनिर्देश और कार्यान्वयन के बीच लंबे समय तक। व्यवसाय विश्लेषक परियोजना की शुरुआत से पहले आवश्यकता को एकत्र करता है और तैयार करता है। | विनिर्देश और कार्यान्वयन के बीच कम समय। उत्पाद स्वामी प्रत्येक स्प्रिंट में टीम की आवश्यकताओं और अपडेट को तैयार करता है। |
| समस्याओं की खोज के लिए एक लंबा समय लगता है। | समस्याओं का शीघ्र पता चलता है। |
| उच्च परियोजना अनुसूची जोखिम। | कम परियोजना अनुसूची जोखिम। |
| परिवर्तनों की शीघ्र प्रतिक्रिया देने की कम क्षमता। | परिवर्तनों के लिए जल्दी से प्रतिक्रिया करने की उच्च क्षमता। |
| परीक्षण चरण विकास चरण के पूरा होने के बाद ही होता है। | परीक्षण आम तौर पर गुणवत्ता सुनिश्चित करने के लिए विकास के समानांतर किया जाता है। |
| ग्राहक केवल आवश्यकता के चरण में शामिल होता है और उसके बाद ग्राहक की कोई भागीदारी नहीं होती है। वह उत्पाद के वितरण के समय ही चित्र में आता है। | ग्राहक पूरे प्रोजेक्ट में शामिल है और ग्राहकों की संतुष्टि सुनिश्चित करने के लिए समय-समय पर फीड बैक ग्राहक से लिया जाता है। |
| उन परियोजनाओं के लिए उपयुक्त जिन्हें स्पष्ट रूप से परिभाषित आवश्यकताएं हैं और जो परिवर्तन की उम्मीद नहीं कर रहे हैं। | उन परियोजनाओं के लिए उपयुक्त जिन्हें विकसित करना है और जिनमें बदलती आवश्यकताएं शामिल हैं। |
| सख्ती से अनुक्रमिक प्रक्रिया। | अत्यधिक सहयोगी सॉफ्टवेयर विकास प्रक्रिया टीम के बेहतर प्रयासों और त्वरित समस्या-समाधान की ओर ले जाती है। |
| एक परियोजना मानसिकता प्रदर्शित करता है। | एक उत्पाद मानसिकता का परिचय देता है और इस प्रकार यह अधिक ग्राहक केंद्रित है। मांग और परिवर्तन प्रक्रिया का हिस्सा हैं |
| औपचारिक और श्रेणीबद्ध। परियोजना प्रबंधक निर्णय निर्माता है। | यह अनौपचारिक है। निर्णय लेने के लिए पूरी टीम जिम्मेदार है। |
| यह मॉडल अनुमान लगाता है कि पूरे प्रोजेक्ट में आवश्यकताओं में कोई बदलाव नहीं होगा। | यह मॉडल अनुकूलन पर आधारित है और यह परिवर्तनों को गले लगाता है। |
| व्यक्ति के काम और परियोजना की प्रगति की स्थिति को सत्यापित करने के लिए मैन्युअल दस्तावेज़ बनाने की आवश्यकता है। | प्रोजेक्ट प्रगति और व्यक्ति की कार्य स्थिति को सत्यापित करने के लिए कानबन चार्ट और बर्न डाउन चार्ट का अनुसरण करता है। |
हमने फुर्तीली और झरने के तरीकों के बीच अंतर और प्रत्येक के लाभों और चुनौतियों के बारे में पर्याप्त चर्चा की। आइए अब हम फुर्तीले परीक्षण बनाम झरना परीक्षण के बीच के अंतरों का पता लगाएं।
चंचल परीक्षण बनाम झरना परीक्षण के बीच अंतर
सॉफ्टवेयर परीक्षण के दृष्टिकोण से, हमारे लिए यह विचार करना महत्वपूर्ण है कि एजाइल परीक्षण वाटरफॉल परीक्षण से कैसे भिन्न है।
| झरना परीक्षण | चंचल परीक्षण |
|---|---|
| टेस्ट टीमों और विकास टीमों को एक स्पष्ट सीमा से अलग किया जाता है और उनके बीच एक सख्त और औपचारिक संचार होता है। | टेस्ट टीम और विकास टीमों को एक टीम के रूप में एकीकृत किया गया है और उनके बीच संचार का एक स्वतंत्र प्रवाह है। |
| परीक्षण विकास के पूरा होने के बाद शुरू होता है और चरण बनाता है। | विकास चरण के साथ परीक्षण समवर्ती शुरू होता है। |
| परीक्षण चरण से ठीक पहले योजना बनाई जाती है। | परियोजना शुरू होने से पहले योजना बनाई जाती है और अक्सर परियोजना के दौरान किया जाता है। |
| परियोजना के दौरान परीक्षण योजना की समीक्षा शायद ही कभी की जाती है। | हर स्प्रिंट के बाद परीक्षण योजना की समीक्षा की जाती है। |
| परीक्षण टीम के लिए आवश्यकताओं में किसी भी परिवर्तन का प्रस्ताव करना चुनौतीपूर्ण है। | परीक्षण टीम सक्रिय रूप से आवश्यकता सभा और परिवर्तन प्रक्रिया में भाग लेती है। |
| सभी कार्यात्मकताओं के लिए एक बार टेस्ट केस बनाए जाते हैं। | टेस्ट केस स्प्रिंट द्वारा स्प्रिंट द्वारा बनाए जाते हैं जो प्रत्येक स्प्रिंट में जारी किए जाने की आवश्यकता होती है। |
| स्वीकृति परीक्षण एक बार जारी होने के बाद ग्राहक द्वारा किया जाता है। | स्वीकृति परीक्षण प्रत्येक पुनरावृत्ति के बाद और व्यवसाय विश्लेषक या परीक्षण टीम द्वारा डिलीवरी से पहले किया जा सकता है। बाद में, यह हर रिलीज के बाद ग्राहक द्वारा किया जाता है। |
| वर्बोज़ और व्यापक परीक्षण प्रलेखन। | टेस्ट डॉक्यूमेंटेशन केवल आवश्यकतानुसार ही किया जाता है। |
| टेस्ट अनुमान और असाइनमेंट अक्सर टेस्ट मैनेजर की जिम्मेदारी होते हैं। | परीक्षण अनुमान और असाइनमेंट टीम और परीक्षण इंजीनियरों की साझा जिम्मेदारी है जो अनुमान प्रदान करने और अपने कार्यों को चुनने में शामिल हैं। |
| प्रतिगमन परीक्षण शायद ही कभी किया जाता है, और इसमें सभी परीक्षण मामलों का निष्पादन शामिल है। | प्रतिगमन परीक्षण प्रत्येक पुनरावृत्ति के बाद किया जाता है और इसमें केवल उन परीक्षण मामलों को शामिल किया जाता है जिनकी आवश्यकता होती है। |
निष्कर्ष
इस लेख में, हमने आधुनिक चुस्त दृष्टिकोण और सॉफ्टवेयर विकास के पारंपरिक झरना पद्धति और प्रत्येक मॉडल के पेशेवरों और विपक्षों को कवर करने वाले एक तुलनात्मक तालिका के साथ परीक्षण के सटीक अंतरों को सीखा।
इस आलेख में सूचीबद्ध सभी कारकों पर विचार करके, हम सॉफ़्टवेयर एप्लिकेशन को विकसित करने के लिए सही सॉफ़्टवेयर डेवलपमेंट लाइफ साइकिल मॉडल का चयन कर सकते हैं। यह कहने में कोई संदेह नहीं है कि वॉटरफॉल मॉडल के ऊपर चंचल कार्यप्रणाली पसंद की जाती है। 90% कंपनियां सॉफ्टवेयर एप्लिकेशन को विकसित करने के लिए एजाइल वर्कफ़्लो को पसंद करती हैं और उसका पालन करती हैं।
चुस्त कार्यप्रणाली सभी प्रकार की परियोजनाओं के लिए अच्छी है। बहुत कम कंपनियां झरना पद्धति का पालन करती हैं। यह कार्यप्रणाली केवल तभी उपयुक्त है जब आवेदन छोटा, सरल हो और आवश्यकता में कोई परिवर्तन न हो।
कुछ मामलों में, हम जरूरतों के आधार पर स्पाइरल, वी और वी, और प्रोटोटाइप नामक अन्य तरीकों का भी विकल्प चुनते हैं।
आशा है कि यह जानकारी आपके लिए यह तय करने में सहायक होगी कि आपकी परियोजना के लिए सबसे अच्छा मॉडल कौन सा है। आप के लिए भी जा सकते हैं हाइब्रिड मॉडल प्रत्येक विधि के विपक्ष को हटाते हुए - यहां चर्चा की गई।
अनुशंसित पाठ
- केस स्टडी: हाइब्रिड मॉडल का उपयोग करके झरने और फुर्तीली विकास प्रक्रियाओं के दोषों को कैसे कम करें
- एसडीएलसी झरना मॉडल क्या है?
- ज़ेफियर एंटरप्राइज टेस्ट मैनेजमेंट टूल रिव्यू - एजाइल टूल में वॉटरफॉल मॉडल एसेट्स का उपयोग कैसे करें
- वर्जनऑन ट्यूटोरियल: ऑल-इन-वन एजाइल प्रोजेक्ट मैनेजमेंट टूल गाइड
- जीरा पोर्टफोलियो ट्यूटोरियल: JIRA के लिए एजाइल प्रोजेक्ट पोर्टफोलियो मैनेजमेंट प्लग-इन (समीक्षा)
- 2021 में शीर्ष 10 सर्वश्रेष्ठ चुस्त परियोजना प्रबंधन उपकरण
- चंचल अनुमान तकनीक: एक चुस्त परियोजना में एक सच्चा अनुमान
- 4 कदम एजाइल प्रक्रिया के लिए सफल संक्रमण के लिए चुस्त परीक्षण मानसिकता का विकास