YT YouTube2Text

YouTube2Text → Transcripts → Lecture 09: Life Cycle Models - V

Lecture 09: Life Cycle Models - V — Transcript

by NPTEL IIT Kharagpur · 3,315 words · 480 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:06इस व्याख्यान में आपका स्वागत है।
0:09पिछले व्याख्यान में, हमने विकासवादी
0:12मॉडल, सर्पिल मॉडल के बारे में चर्चा
0:15की थी और सिर्फ फुर्तिल विकास की शुरुआत
0:19की थी।फुर्तीले मॉडल बहुत लोकप्रिय हो
0:22गए हैं।हम देखेंगे कि विशेष रूप से अभी
0:27जो परियोजनाएं चल रही हैं, उनके लिए
0:30बहुत सारे फायदे हैं।शुरुआत में,
0:33हमने कहा था कि जिस प्रकार की परियोजनाएँ
0:37शुरू की गई हैं, उनमें पिछले कुछ वर्षों
0:41में भारी बदलाव आया है।अब परियोजनाएँ
0:44बहुत छोटी अवधि की हैं; 1 महीने, 2 महीने
0:48या 3 महीने की परियोजनाएं बहुत आम हैं जबकि,
0:53पहले मल्टीएयर(multi year) परियोजनाएं ; 3 साल,
0:564 साल, 5 साल की परियोजनाएं और अब बहुत से पुन:
1:02उपयोग केवल अनुकूलन कार्य किया जा रहा
1:05है।
1:06इसलिए, यह सेवा प्रकार की परियोजनाएं हैं।पहले
1:09हमारे पास खरोंच से उत्पाद विकास
1:12था, अब यह अनुकूलन है।
1:15पहले अधिकांश परियोजनाएं इस तरह की होती जा
1:19रही हैं कि ग्राहक की ओर से कम विकास
1:24परिनियोजन पे प्रतिक्रिया मिल रही है और इसी
1:28तरह से।और उस संबंध में, फुर्तीली मॉडल
1:31बहुत फायदेमंद है और हमने फुर्तीले
1:34मॉडल के बारे में चर्चा करना शुरू
1:38कर दिया था।
1:40आइए हम फुर्तीले मॉडल के अधिक विवरणों
1:43को देखें।पिछली बार हमने देखा था कि फुर्तीले
1:47मॉडल में कुछ विशेषताएं शामिल हैं जैसे ग्राहक
1:51भागीदारी, वृद्धिशील विकास, एकीकरण और
1:54प्रत्येक पुनरावृत्ति पर परीक्षण, ग्राहक
1:56स्थल पर तैनाती, कम प्रलेखन और इतने
2:00पर।
2:01अब, हम फुर्तीली मॉडल की मुख्य तकनीकों
2:04को देखते हैं।यहां कोई औपचारिक आवश्यकताएं
2:07विकसित नहीं हुई हैं;उपयोगकर्ता कहानियों
2:10पर आधारित है; जैसा कि नाम का कहना है
2:14कि ये एक आवश्यकताओं के विनिर्देशन से
2:18अधिक अनौपचारिक हैं।ये कहानी की तरह हैं;
2:21ये उपयोग के मामलों की तुलना में सरल
2:25हैं।एक समग्र डिजाइन परिप्रेक्ष्य देने
2:28के लिए, फुर्तीली मॉडल रूपकों का प्रस्ताव
2:32करता है जहां एक सामान्य दृष्टि है जो आवश्यक
2:36है और इसके आधार पर विकास शुरू होता
2:40है।जहां कहीं भी स्पाइक की आवश्यकता
2:43होती है; स्पाइक एक साधारण प्रोग्राम
2:46है जिसे संभावित समाधान का पता लगाने
2:50के लिए लिखा जाता है।
2:53हम देख सकते हैं कि यह एक प्रोटोटाइप
2:57के समान है।जहां भी अनिश्चितता है
3:00वहां स्पाइक विकसित करें, विकल्प की जांच
3:03करें कि क्या स्पाइक अच्छा प्रदर्शन करता
3:07है और इसी तरह प्रतिक्षेपक भी।
3:10एक बार जब इसे ग्राहक साइट पर विकसित किया
3:14जाता है और ग्राहक इसे स्वीकार कर लेता
3:19है, तो कोड को उस व्यवहार को प्रभावित किए
3:23बिना पुन: व्यवस्थित करता है जैसे कि कोड
3:27अधिक संरचित हो जाता है, कोड में कुछ डिज़ाइन
3:32डालते हैं।इसलिए, जैसा कि आप देख सकते
3:35हैं कि प्रत्येक पुनरावृत्ति के बाद
3:38डिजाइन को कोडित किया गया है।
3:42प्रारंभ में कोड को काम करने के लिए
3:46बनाया गया है और फिर इसका पुनर्गठन किया
3:50गया है, हमारे पास रूपक है जहां समग्र
3:54डिजाइन और इसी तरह की कुछ सामान्य दृष्टि
3:58है।
3:59यह वृद्धिशील है; हर बार जब एक वृद्धि
4:02की योजना बनाई जाती है और ग्राहक स्थल
4:07पर तैनात की जाती है, तो कोई दीर्घकालिक
4:11योजना नहीं बनाई जाती है।
4:13इटरेशन (Iteration) महत्वपूर्ण कार्यक्षमता नहीं
4:16जोड़ सकता है, यह केवल मौजूदा कार्यक्षमता
4:19को बढ़ा सकता है।
4:21लेकिन तब प्रत्येक पुनरावृत्ति के अंत
4:24में, कोड को ग्राहक साइट पर तैनात किया
4:29जाता है और पुनरावृत्ति की लंबाई आमतौर पर
4:332 से 4 सप्ताह की तरह कुछ तय की जाती है।और
4:38यहां याद रखें कि प्रत्येक पुनरावृत्ति
4:41के बाद, ग्राहक कोड बनाता है; कोड को नियमित
4:46उपयोग में लाता है।
4:48ऐसा नहीं है कि वे सिर्फ इसका मूल्यांकन
4:52करते हैं, वे बस इसका उपयोग नियमित रूप
4:56से करने लगते हैं।
4:58जैसा कि हम कह रहे हैं कि फुर्तीली
5:02मॉडल, एक महत्वपूर्ण बात है संचार आमने
5:06सामने है ।यह आवश्यक है कि विकासकर्ता
5:09उसी भवन या उसी कमरे को साझा करें, जो वे
5:14नियमित रूप से मिलते हैं दस्तावेजों को
5:18एक-दूसरे को पास करने के बजाय मुद्दों
5:22पर चर्चा करें जो वे करते हैं और एक-दूसरे
5:26को समझाते हैं कि क्या आवश्यक है और
5:30इसी तरह आमने-सामने संचार की सुविधा
5:33के लिए, वे एक ही कार्यालय स्थान साझा करते
5:38हैं और आमतौर पर टीम का आकार 5 से 9 लोगों
5:44के लिए होता है, ताकि वे अच्छी तरह से बातचीत
5:49कर सकें।
5:50और यह फुर्तीले मॉडल को छोटी परियोजनाओं
5:53के लिए अनुकूल बनाता है,लेकिन निश्चित
5:56रूप से, बड़ी परियोजनाओं के लिए इसका उपयोग
6:00करने का प्रयास किया गया है।लेकिन तब
6:04इसकी शुरुआत छोटी परियोजनाओं पर केंद्रित
6:07थी।यहां एक बात का उल्लेख करने की आवश्यकता
6:11है कि जब किसी को कुछ बताना है, तो उसे पढ़ने
6:17के लिए एक दस्तावेज देना अच्छा नहीं
6:20है।यदि आप उसे एक व्हाइटबोर्ड पर समझा
6:24सकते हैं जो सबसे अच्छा तरीका है, तो
6:28आप उसे समझा सकते हैं; आप एक दस्तावेज़
6:32पास करते हैं या उसे फ़ोन या ईमेल पर समझाते
6:37हैं जो एक अच्छा विचार नहीं है।
6:41वास्तव में, विभिन्न संचार विधियों की
6:44प्रभावशीलता को खोजने के लिए प्रयोग किए
6:47जाते हैं।यह प्रयोगों से एलिस्टेयर कॉकबर्न
6:50द्वारा दिया गया है; वह यह निर्धारित
6:54कर सकता है कि कागज संचार का एक ठंडा
6:59रूप है जो बहुत प्रभावी नहीं है।।
7:02यदि आप किसी को कुछ बताना चाहते हैं
7:06तो उसे एक पेपर दें, विशेष रूप से तकनीकी
7:11संचार संवाद करने का एक अच्छा तरीका
7:14नहीं है।ऑडियो टेप कागज से थोड़ा बेहतर
7:18है।ईमेल वार्तालाप थोड़ा बेहतर हो सकता
7:21है; वीडियो टेप थोड़ा बेहतर है, वीडियो
7:25बातचीत अभी भी बेहतर है और एक व्हाइटबोर्ड
7:29के साथ बातचीत का सामना करना पड़ता
7:32है।यह तकनीकी वस्तुओं को संवाद करने का
7:36सबसे प्रभावी तरीका है; यह यहां की खोज
7:40थी।
7:41इसलिए, वे व्हाइटबोर्ड के साथ एक छोटी टीम
7:45से मिलते हैं और एक व्यक्ति व्हाइटबोर्ड
7:48पर अपने विचारों को समझाता है जो संचार
7:52के लिए सबसे प्रभावी तरीका है और जो इस
7:57मॉडल में शामिल है; आमने-सामने संचार
8:00को महत्व दिया जाता है।
8:02यहां पर प्रगति को मापा जाता है कि ग्राहक
8:07साइट पर कितने वृद्धि को तैनात किया गया
8:11है।हर कुछ हफ्तों में एक बार संस्करणों
8:15वितरित होती है।ग्राहक वितरित संस्करणों
8:17का उपयोग करता है और आवश्यकता परिवर्तन
8:21देता है।इन्हें समायोजित किया जाता है, ग्राहक
8:24और विकासकर्ता के बीच एक करीबी सहयोग
8:28होता है और टीम के सदस्यों के बीच आमने-सामने
8:33संचार होता है।ये फुर्तीले मॉडल के
8:36कुछ मूलभूत सिद्धांत हैं।
8:38लेकिन प्रलेखन के बारे में क्या फुर्तीले
8:41मॉडल में किया गया कोई दस्तावेज नहीं
8:45है, वास्तव में नहीं।यहाँ विचार प्रकाश का
8:48यह है कि जब तक कि आपको आवश्यकता न
8:53हो, आप दस्तावेज़ न दें।
8:56जितना आपको लगता है उससे कहीं कम प्रलेखन
9:00की आवश्यकता है।झरना मॉडल में, सब कुछ प्रलेखित
9:04होने की आवश्यकता है; समीक्षा परिणाम,
9:07योजनाएं, आवश्यकता समीक्षा, डिजाइन,
9:09उच्च स्तरीय डिजाइन, उच्च स्तरीय डिजाइन
9:12समीक्षा सब कुछ प्रलेखित है।लेकिन यहां, मुख्य
9:15विचार यह है कि दस्तावेजों को केवल तभी तैयार
9:20करने की आवश्यकता होती है जब इन्हें
9:24किसी के द्वारा लंबे समय से संदर्भित
9:27किया जाना आवश्यक हो।लेकिन फिर भी
9:30ये संक्षिप्त हैं; ये दस्तावेज़ केवल
9:33उन सूचनाओं के लिए तैयार किए गए हैं
9:37जो कि विकास की चीज़ों के अंत में, जिनके
9:42बदलने की संभावना नहीं है, नहीं है।
9:46इसलिए, विकास दस्तावेजों को अंत में तैयार
9:49किया जाता है और यहां केवल उन चीजों का
9:54दस्तावेजीकरण किया जाता है, जहां कोई
9:57व्यक्ति कुछ सीख सकता है, जो किसी व्यक्ति
10:01के लिए बहुत जानकारीपूर्ण होगा, जिसे जानना
10:04अच्छी बात है।ऐसा नहीं है कि प्रलेखन
10:08हो, प्रलेखन बनाया जाता है।
10:11दस्तावेज़ पर्याप्त रूप से सटीक, सुसंगत
10:14और विस्तृत हैं क्योंकि ये तब तैयार किए जाते
10:18हैं जब अधिक परिवर्तन नहीं होते हैं।दस्तावेज़
10:22के कुछ वैध कारण यह हैं कि परियोजना
10:26के हितधारकों को इसकी आवश्यकता है;उदाहरण
10:29के लिए, ग्राहक को इसकी आवश्यकता हो
10:32सकती है, हो सकता है कि एक अनुबंध फ़ॉर्म
10:37पर हस्ताक्षर किए जाएं जिसके लिए इसकी
10:41आवश्यकता है,हो सकता है कि कोई बाहरी समूह
10:45है जो अपने सुझावों की समीक्षा करना
10:48या देना पसंद करता है, हो सकता है कि
10:53दस्तावेज़ उनके लिए होगा, शायद दस्तावेज़
10:56उन लोगों के लिए होगा जिन्हें परियोजना
11:00समाप्त होने के बाद संदर्भित किया जाएगा।
11:03केवल जब दस्तावेज़ के वैध कारण होते
11:07हैं, तो दस्तावेज़ तैयार किए जाते हैं।
11:10ऐसा नहीं है कि दस्तावेजों को चूक से तैयार किया
11:15जाता है जैसा कि हां झरना मॉडल के मामले
11:20में है।
11:21विकास के समय और नई आवश्यकताओं के आने
11:25के बाद यहां की आवश्यकताएं बदल रही हैं, उन्हें
11:30यहां आवश्यकताओं के स्टैक में रखा
11:33जाता है।स्टैक को प्राथमिकता दी जाती
11:36है कि शीर्ष पहले हैं जिन्हें पहले
11:39लिया जाएगा।ये उच्च प्राथमिकता हैं और
11:42ये सभी आवश्यकताएं हैं और स्कॉट एंबलर्स
11:46द्वारा दिए गई पुस्तक में इस आरेख की आवश्यकताएं
11:51उत्पन्न होती रहती हैं।
11:53उन्हें स्टैक में डाला जाता है, जब भी
11:57आवश्यक होता है उन्हें हटा दिया गया है उन्हें
12:01बदल दिया जाता है; उनकी पुनरावृत्ति
12:04हुई, लेकिन तब प्रत्येक आवश्यकता के लिए
12:08प्राथमिकता दी जाती है और फिर इसे गतिशील
12:12रूप से बदल दिया जाता है।
12:15फुर्तीली मॉडल के कई फायदे हैं, लेकिन
12:19फिर इसे व्यावहारिक रूप से उपयोगी बनाने
12:22के लिए, आपको कुछ नुकसानों के बारे में पता होना
12:27चाहिए।पहली बात तो यह कि यहां दस्तावेज
12:31नहीं हैं।यह एक व्हाइटबोर्ड और इतने पर स्पष्टीकरण
12:35पर आधारित है।
12:37और इसलिए, कोई गलत समझ सकता है।
12:40उच्च गुणवत्ता वाले लोगों के कौशल की
12:44आवश्यकता होती है जो संदेह में होने
12:47पर एक-दूसरे से परामर्श करेंगे और वही करेंगे
12:51जो सही है।दीर्घकालिक डिजाइन नहीं बनाया
12:54गया है और छोटे पुनरावृत्तियों, ये डिजाइन संरचना
12:58कम अच्छी दिखाती हैं।
13:01वहाँ हो सकता है फीचर क्रीप ,फीचर क्रिप
13:05वह शब्द है जहां ग्राहक या विकासकर्ता अधिक
13:09महत्वाकांक्षी हो जाते हैं।
13:11वे बस नई सुविधाओं के बारे में सोचते
13:15रहते हैं जिन्हें इस बात के बिना शामिल
13:19किया जा सकता है कि इस सुविधा का कितना
13:24उपयोग किया जाएगा; ग्राहक के लिए इसका
13:27मूल्य क्या होगा,इसे विकसित करने की लागत
13:31क्या होगी, फीचर के जुड़ने के बाद । इसलिए,
13:35फुर्तीले मॉडल में फीचर क्रिप का अधिक
13:38जोखिम है क्योंकि प्रतिक्रिया देने
13:41की स्वतंत्रता है और नई सुविधा देने
13:44के लिए अनुरोध दिया जाता है।
13:48और इसलिए, परियोजना प्रबंधक के लिए फीचर
13:51क्रीप प्रबंधित करना मुश्किल हो जाता
13:54है और चूंकि विकास गतिशील है, सुविधाएँ
13:58बदल जाती हैं नई सुविधाएँ जुड़ जाती हैं और
14:02इसी तरह।एक विकास के लिए एक अग्रिम
14:06लागत देने के लिए बहुत मुश्किल हो
14:09जाता है; एक ऐसा समय-समय देना जिसके द्वारा
14:14विकास किया जाएगा और यह सुनिश्चित
14:17करना मुश्किल है कि गुणवत्ता कठिन
14:20है और अधिक कठिन है।
14:22दस्तावेज़ जो किया गया है वह एक अच्छी
14:26बात है दस्तावेज़ तैयार करने के समय
14:30के प्रयास को बचाता है, लेकिन फिर यह जानना
14:34चाहिए कि दस्तावेज़ की कमी है।गलत व्याख्या
14:38की संभावना हो सकती है,दस्तावेज़ पर
14:41समीक्षा प्राप्त करना मुश्किल है
14:44और यह भी कि जब तक परियोजना पूरी नहीं
14:48हो जाती है, जब तक कि परियोजना के अंत
14:53में दस्तावेजों को सचेत रूप से तैयार
14:56नहीं किया जाता है, टीम के आने से पहले,
15:01तब रखरखाव मुश्किल हो सकता है।
15:04फुर्तीली मॉडल की इस समग्र समझ के साथ,
15:08हम कुछ विशिष्ट फुर्तील प्रक्रियाओं को देखते
15:12हैं।फुर्तीली प्रक्रिया में से एक जो बहुत
15:15लोकप्रिय है वह चरम प्रोग्रामिंग है
15:18जिसे XP मॉडल के रूप में भी जाना जाता
15:23है।
15:24यह केंट बेक, 1999 द्वारा प्रस्तावित किया
15:27गया था।
15:28यहां पेश किए जाने वाले मुख्य मद जोड़ी
15:32प्रोग्रामिंग (programming)हैं।एक जोड़ी प्रोग्रामिंग
15:34(programming) में, प्रत्येक डेस्क प्रत्येक डेस्कटॉप
15:37दो प्रोग्रामर (programmer)द्वारा संचालित होता है।जब
15:40एक प्रोग्रामर (programmer) प्रोग्राम( program) लिखता
15:43है, तो दूसरे प्रोग्रामर( programmer) कोड (code) से गुजरते
15:48हैं और यह सुझाव देता है कि इसे बेहतर कोड,
15:53अधिक कुशल कोड बनाने, गलतियों से बचने
15:57और इतने पर सुझाव देते हैं और एक घंटे
16:01के लिए एक प्रोग्रामर प्रोग्राम प्रोग्राम
16:04को ले जाएं, शायद कुछ फ़ंक्शन लिखता है
16:08और फिर दूसरा प्रोग्रामर लेता है, कुछ और फ़ंक्शन
16:13लिखता है जहां पहला प्रोग्रामर समीक्षा
16:16करता है।
16:17यहां हर दिन परीक्षण ,झरना के मॉडल के विपरीत
16:22होता है जहां परीक्षण अंत में होता है।यहां
16:26परीक्षण मामलों को लगातार लिखा जाता
16:29है और एक विशेषता के पारित होने से
16:33पहले परीक्षण मामलों को निष्पादित किया
16:36जाता है।
16:37किसी विशेषता को लागू करने से पहले,
16:41परीक्षण के मामलों को उस सुविधा के लिए
16:45लिखा जाता है और परीक्षण के मामलों को पारित
16:49करने पर इस सुविधा को पारित माना जाता
16:53है।इसे परीक्षण संचालित विकास कहा जाता है।
16:57यहाँ वृद्धिशील विकास का अभ्यास किया जाता
17:00है हर दिन कुछ वृद्धि दी जाती है।
17:05चरम प्रोग्रामिंग नाम इस तथ्य से आता
17:08है कि अच्छी प्रथाओं को चरम पर ले जाया
17:13जाता है।अच्छी प्रथाओं कोड की समीक्षा अच्छी
17:16है और यह जोड़ी प्रोग्रामिंग परीक्षण के रूप में
17:21लागू किया गया है जो अच्छा है; अच्छा
17:25अभ्यास और इसलिए संचालित विकास का
17:28परीक्षण करता है । वृद्धिशील विकास
17:31अच्छा है, इसलिए हर कुछ दिनों में नई
17:35वृद्धि दी जाती है।
17:37सादगी अच्छी है और इसलिए, सबसे सरल डिजाइन
17:41विकसित किया गया है।दशकों के बाद
17:44या लंबे समय के लिए आवश्यक विस्तारके
17:47बारे में सोचने की कोशिश न करें, बाद
17:52में कुछ वृद्धि की आवश्यकता हो सकती
17:55है; वह मत सोचो।
17:57अब, यह काम करते हैं सबसे सरल डिजाइन
18:01बनाने के लिए यह काम करते हैं।डिजाइनिंग
18:05अच्छी है और इसलिए, सॉफ़्टवेयर के स्वीकृत
18:08होने के बाद, कोड को प्रतिक्षेपक करें,
18:12कुछ डिज़ाइन डालें, कोड को बेहतर आर्किटेक्चर
18:16(architecture) बनाना महत्वपूर्ण है और इसलिए,एक रूपक
18:19को परिभाषित करना होगा।
18:21चार मूल्य यहां; संचार का सामना करने के
18:25लिए संचार, सरलता, सरलतम डिजाइन को
18:28लागू करें कल के लिए ध्यान न दें यह काम
18:33कर सकता है।
18:35प्रतिक्रिया से ग्राहकों की प्रतिक्रिया मिलती
18:38है, ग्राहक प्रतिक्रिया को प्रोत्साहित करते
18:41हैं।
18:42यदि आपको ग्राहक से प्रतिक्रिया नहीं
18:45मिलती है, तो यह होने वाली परेशानी है
18:49क्योंकि अंत में वे अस्वीकार कर देंगे;
18:52वे दुखी होंगे।और यहाँ दूसरा मूल्य
18:55साहस है।
18:56यदि कुछ कोड अच्छा नहीं है, इसे रद्द
19:00करें तो उसे फिर से लिखें।डिजाइन अच्छा
19:04नहीं है, इसे रद्द करेंडिजाइन को त्यागें;
19:08डिज़ाइन को फिर से करें।
19:10कोडिंग एक सर्वोत्तम अभ्यास है जिसमें
19:13कोडिंग परीक्षण पर अत्यधिक ध्यान दिया
19:16जाता है, यह एक सर्वोत्तम अभ्यास है जो प्राथमिक
19:21रूप से दोष मुक्त सॉफ्टवेयर के विकास
19:24का है और इसलिए, परीक्षण और सुनने के लिए महत्व
19:30एक सर्वोत्तम अभ्यास है ग्राहक को सुनें
19:33और पता करें कि ग्राहक को वास्तव में क्या
19:38आवश्यक है।
19:39उचित डिजाइन के बिना डिजाइनिंग, सिस्टम
19:42जटिल हो जाता है।इसलिए, सिस्टम में डिज़ाइन
19:45डालें।और प्रतिक्रिया एक महत्वपूर्ण बात
19:48है ग्राहक प्रतिक्रिया प्राप्त करें।
19:50परीक्षण संचालित विकास पर जोर देता
19:54है; उपयोगकर्ता कहानी के आधार पर, पहले परीक्षण
19:58मामलों को विकसित करें कोड लिखने से
20:01पहले, पहले परीक्षण मामलों को लिखें
20:04जिससे परीक्षण संचालित विकास हो।
20:07पहले उपयोगकर्ता की कहानी के आधार
20:10पर परीक्षण के मामले लिखें और फिर इसे
20:14लागू करें।एक बार कार्यान्वित होने
20:17के बाद परीक्षण के मामले चलते हैं और
20:21विकास तब तक पूरा नहीं होता है जब तक
20:25कि यह सभी परीक्षण मामलों को पारित
20:29न कर दे।वृद्धि पर हर कुछ दिनों में
20:33वेतन वृद्धि दी जाए, ग्राहक प्रतिक्रिया
20:36प्राप्त करें, यदि आवश्यक हो तो बदल
20:39सकते हैं और फिर अंत में, एक बार ग्राहक
20:44के कारक द्वारा स्वीकार किए जाने के बाद, कोड
20:49को बेहतर बनाएं, कुछ डिज़ाइन डालें और
20:52फिर अगली सुविधा लें।
20:54अब, हम कुछ अभ्यास प्रश्नों को देखते
20:58हैं ..अब तक, जिन बिंदुओं पर चर्चा हुई है; पुनरावृत्ति
21:03जलप्रपात मॉडल के चरण क्या हैं।
21:06आशा है कि आपको याद होगा, अगर नहीं तो
21:11कृपया देखें; पुनरावृत्त जलप्रपात मॉडल के
21:14प्रमुख नुकसान क्या हैं।
21:16क्योंकि बाद के मॉडलों को पुनरावृत्त जल
21:19गिरावट मॉडल के नुकसान को दूर करने का प्रस्ताव
21:24दिया गया था, जिस पर आपने पहले ही चर्चा
21:28की थी।झरना मॉडल के साथ कई समस्याएं,
21:32सबसे महत्वपूर्ण परिवर्तन आवश्यकताओं
21:34को संभालने में कठिनाई है, फुर्तीला मॉडल
21:38इतना लोकप्रिय क्यों हो गया है,झरना के
21:41मॉडल की कौन-सी समस्याएं इससे दूर हुईं, यह
21:45वर्तमान प्रकार की परियोजनाओं में कैसे
21:48फिट बैठता है,यदि कोई जीवन चक्र मॉडल
21:52एक निश्चित बड़े परियोजना में ठीक
21:55नहीं है, तो किस कठिनाई का सामना करना पड़
22:00सकता है।
22:01अब, हम एक और फुर्तीली विकास प्रक्रिया
22:04को देखते हैं जिसे जमघट कहा जाता है।
22:08जमघट की मुख्य विशेषताएं स्वयं आयोजन टीमें
22:12हैं यह टीम के सदस्य आपस में तय करते हैं
22:17कि कौन क्या करेगा, कौन परीक्षण करेगा,
22:21कौन कौन से कार्य विकास वगैरह करेंगे।यहां
22:24उत्पाद महीने लंबे स्प्रिंट की श्रृंखला
22:27में आगे बढ़ता है; स्प्रिंट मूल रूप
22:31से वेतन वृद्धि हैं।
22:33इसलिए, वृद्धि को आम तौर पर स्प्रिंट
22:36एक महीने के लिए कहा जाता है।यहां आवश्यकताओं
22:40पर कब्जा कर लिया गया है, हम आवश्यकताओं
22:45को कुछ इस तरह से देख रहे हैं जिसे उत्पाद
22:50बैकलॉग कहा जाता है।
22:52इसलिए, फुर्तीली प्रक्रियाओं में
22:54से एक; यहां उन आवश्यकताओं को इकट्ठा किया गया
22:58है जो विकास के रूप में उत्पन्न होती
23:02हैं, क्योंकि कुछ हटाई जा सकती हैं,
23:06बदल सकती हैं और इसी तरह आगे बढ़ सकती
23:11हैं।
23:12इसे उत्पाद बैकलॉग कहा जाता है।प्रत्येक
23:14स्प्रिंट में, एक स्प्रिंट एक महीने
23:17की लंबी गतिविधि है।स्प्रिंट बैकलॉग
23:20बनाने वाले शीर्ष प्राथमिकता सुविधा
23:22की आवश्यकता में से एक को लिया जाता
23:26है और एक बार स्प्रिंट बैकलॉग प्राप्त करने
23:30के बाद, यह अब नहीं बदला जाता है।यह
23:35बदलने के लिए प्रतिरक्षा है और यह एक महीने
23:39के लंबे चलना पर विकसित किया गया है और हर
23:44दिन विकासकर्ता दैनिक समीक्षा करने के
23:47लिए मुलाकात करते हैं कि क्या हुआ है,
23:51आगे क्या करना है और इसी तरह वे स्प्रिंट
23:56बैकलॉग पूरा करते हैं।
23:58स्प्रिंट बैकलॉग में, पहचान की गई आवश्यकताओं
24:02के आधार पर यहां उन गतिविधियों से जिन्हें
24:06आवश्यकताओं को पूरा करने के लिए किए जाने
24:10की आवश्यकता होती है, की पहचान की जाती
24:14है और जिन्हें स्प्रिंट बैकलॉग में डाल दिया
24:18जाता है, जिसे विकास टीम द्वारा लगाया
24:22जाता है।और इन गतिविधियों को दैनिक जमघट और
24:26अंत में स्प्रिंट समीक्षा पर पूरा
24:29किया जाता है;स्प्रिंट की समीक्षा की जाती
24:32है और उत्पाद वृद्धि ग्राहक स्थल पर तैनात
24:36की जाती है।
24:38तो, यह यहाँ मुख्य विचार है।प्रगति
24:41स्प्रिंट के रूप में होती है, अवधि
24:45आमतौर पर एक महीने होती है।एक महीने
24:48में, उत्पाद बैकलॉग से कुछ सुविधाएँ
24:51ली जाती हैं; डिजाइन, कोडित, परीक्षण किया
24:55गया।और एक बार जब स्प्रिंट शुरू हो
24:58जाता है, तो आवश्यकताओं को बदलने की अनुमति
25:02नहीं है, अन्यथा स्प्रिंट अभिसरण नहीं करेगा।यहां
25:06एक सिद्धांत यह है कि एक बार जब उत्पाद
25:11बैकलॉग से सुविधा ले ली जाती है, तो
25:15उन्हें बदलने की अनुमति नहीं होती
25:18है।
25:19यहाँ कुछ शब्दावली भूमिकाओं, समारोहों
25:21और कलाकृतियों की है।भूमिकाएं उत्पाद
25:23स्वामी हैं।उत्पाद के स्वामी की ओर से
25:27टीम का एक सदस्य कार्य करता है; वह एक ग्राहक
25:32है।उनके पास ग्राहक दृष्टिकोण है, जो
25:35एक जमघट मास्टर है जो एक परियोजना प्रबंधक
25:39और फिर टीम के सदस्यों की तरह है।विकास
25:43के दौरान विभिन्न समारोह होते हैं;एक
25:46स्प्रिंट योजना है, स्प्रिंट के अंत
25:49में स्प्रिंट की समीक्षा, स्प्रिंट
25:52पूर्वप्रभावी और दैनिक स्क्रैम मुलाकात।विभिन्न
25:54कलाकृतियों का उत्पादन किया जाता है एक उत्पाद
25:59बैकलॉग है जो अब तक पहचानी गई आवश्यकताओं
26:03का ट्रैक रखता है, विकास की आय के रूप
26:07में अधिक आवश्यकताओं की पहचान की जा सकती
26:11है और इन्हें प्राथमिकता क्रम में रखा गया
26:15है।स्प्रिंट बैकलॉग यह स्प्रिंट के दौरान
26:18की जाने वाली गतिविधियाँ हैं।
26:21यहां कार्य समय चार्ट की कितनी प्रगति
26:25हुई है, इसे कार्य समय चार्ट के रूप
26:29में दर्शाया गया है।
26:31उत्पाद के मालिक के पास ग्राहक का
26:34दृष्टिकोण है विकास टीम में क्रॉस कार्यात्मक
26:38कौशल वाले पांच से नौ लोग हैं।स्क्रैम
26:41मास्टर को परियोजना प्रबंधक कहा जाता
26:44है।उन्होंने कहा कि टीम के अंदर और
26:48बाहर हस्तक्षेप के दौरान स्कोरर की
26:51सुविधा बफर है और टीम के सदस्यों के
26:55सामने आने वाली कठिनाइयों को हल करता है।
26:59उत्पाद का मालिक टीम के सदस्यों में
27:03से एक या शायद ग्राहक प्रतिनिधि में से
27:07एक है जो टीम का हिस्सा है।
27:11वह ग्राहक के प्रतिनिधि के रूप में कार्य
27:15करता है।वह वो है जो यह बताता है कि
27:19रिलीज की तारीख पर निर्णय लेने के लिए
27:23क्या विशेषताएं हैं।
27:25बाजार मूल्य क्या होगा इसके अनुसार
27:28ग्राहक के दृष्टिकोण के आधार पर सुविधाओं
27:31को प्राथमिकता दें, प्रत्येक पुनरावृत्ति
27:34में उत्पाद बैकलॉग में सुविधाओं और
27:37प्राथमिकता को समायोजित करें और अंत में, परिणामों
27:41को स्वीकार या अस्वीकार करें।
27:44हमने जमघट के पीछे का मुख्य विचार देखा
27:48है।
27:49जमघट में कई शब्दावली हैं; कुछ शब्दावली
27:52में देखा गया है और हम इस व्याख्यान
27:56के अंत में आ रहे हैं और फुर्तीले मॉडल
28:01में कुछ और शब्दावली और अवधारणाएं इस
28:04व्याख्यान में चर्चा नहीं कर सकती हैं।हम
28:08अगले व्याख्यान में भाग लेंगे और अगले
28:11व्याख्यान में विकास के जीवन चक्र पर अपनी
28:15चर्चा पूरी करेंगे।

About this transcript

This page contains the full transcript of Lecture 09: Life Cycle Models - V by NPTEL IIT Kharagpur, generated from the public captions YouTube serves with the video. The transcript has 3,315 words across 480 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.