YT YouTube2Text

YouTube2Text → Transcripts → Lecture 01: Introduction - I

Lecture 01: Introduction - I — Transcript

by NPTEL IIT Kharagpur · 3,206 words · 486 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:07सॉफ्टवेयर प्रोजेक्ट मैनेजमेंट कोर्स
0:15में आपका स्वागत है।
0:23जैसा कि पहले प्रदर्शित किया गया है कि पाठ्यक्रम
0:42का संचालन स्वयं मैं और प्रोफेसर
0:54दुर्गा प्रसाद महापात्रा करेंगे।
1:02मेरा नाम राजीब मॉल है जैसा कि आप डिस्प्ले
1:21पर देख सकते हैं।
1:29मैं आईआईटी खड़गपुर के कंप्यूटर विज्ञान
1:42और इंजीनियरिंग विभाग से संबंधित हूं।
1:54आज, हम कुछ परिचयात्मक चर्चा करेंगे।
2:07पहला मेरे बारे में है, मेरा नाम राजीव
2:23मॉल है, मेरी सारी शिक्षा स्नातक, मास्टर
2:38और पीएचडी, इंडियन इंस्टीट्यूट ऑफ साइंस
2:50बैंगलोर से हुई है।
2:58इस प्रकार, इस संस्थान में अध्ययन किया
3:13और फिर लगभग 3 वर्षों तक मोटोरोला इंडिया
3:29के लिए काम किया।
3:38और, फिर 1994 में आईआईटी खड़गपुर में स्थानांतरित
3:54कर दिया गया और वर्तमान में सीएसई विभाग
4:11में एक प्रोफेसर हूं, यह भारतीय प्रौद्योगिकी
4:25संस्थान खड़गपुर भवन है -
4:33आइए हम उन विषयों को देखें, जिन पर हम
4:52इस परिचयात्मक व्याख्यान में चर्चा करेंगे।
5:04हम पहले पता करेंगे कि सॉफ्टवेयर परियोजना
5:19प्रबंधन क्या है?
5:25क्या सॉफ्टवेयर परियोजना प्रबंधन पारंपरिक
5:36परियोजना प्रबंधन से अलग है?
5:46नौकरियों, परियोजनाओं और अन्वेषण कार्य
5:56के बीच क्या अंतर है ? सॉफ़्टवेयर प्रोजेक्ट
6:11योजना क्या मुश्किल है?
6:19और, प्रोजेक्ट स्कोप से हमारा क्या तात्पर्य
6:33है?
6:36यह महत्वपूर्ण क्यों है और कोई परियोजना
6:50के दायरे को कैसे परिभाषित करता है?
7:04तो, ये मूल विषय हैं जिन पर हम इस परिचयात्मक
7:25व्याख्यान में चर्चा करेंगे।
7:33दुनिया भर में 2014 में आईटी का खर्च गार्टनर
7:52रिपोर्ट के आधार पर बहुत बड़ा, लगभग
8:073.5 ट्रिलियन डॉलर रहा है।
8:15और, धीरे-धीरे लगभग 4 ट्रिलियन डॉलर की
8:26वृद्धि हुई और यह भारत के सकल घरेलू
8:40उत्पाद के साथ इसकी तुलना लगभग 2.5 ट्रिलियन
8:51डॉलर है।
8:52इसलिए, आईटी खर्च भारत के सभी घरेलू
8:57उत्पादन से बहुत अधिक है।
9:01और इसलिए, सॉफ्टवेयर हमारे जीवन का एक
9:06बहुत ही महत्वपूर्ण हिस्सा बन गया है,
9:11हम बड़ी मात्रा में पैसा सॉफ्टवेयर में
9:16खर्च करते हैं; हम कई स्थानों पर सॉफ्टवेयर
9:21का सामना करते हैं।
9:24और, विशेष रूप से भारत में हम एक सॉफ्टवेयर
9:30पावरहाउस के रूप में जाने जाते हैं,
9:35बड़ी मात्रा में सॉफ्टवेयर विकसित
9:39होते हैं, बड़ी संख्या में कंपनियां होती
9:44है और वे सॉफ्टवेयर विकसित करने के लिए
9:50बड़ी संख्या में परियोजनाएं शुरू
9:53करती हैं।
9:54तो, यह दुनिया भर में एक महत्वपूर्ण विषय
10:00है।
10:01और, विशेष रूप से भारत के लिए जहां सॉफ्टवेयर
10:07विकास का बड़ा हिस्सा होता है, लेकिन तब
10:13हर कोई कहता है कि एक सॉफ्टवेयर संकट
10:18है।
10:19लेकिन यह संकट क्या है?
10:23आइए पहले हम संकट को समझें।
10:27संकट के क्या लक्षण हैं?
10:30यदि हम उन संकट के लक्षणों को देखते
10:36हैं, ग्राहक के लिए विकसित और वितरित
10:41किया गया सॉफ़्टवेयर अक्सर ग्राहकों की
10:45आवश्यकताओं को पूरा करने में विफल रहता
10:50है, इनमे ये परिवर्तन बहुत महंगा होते
10:55है, डिबग और आगे विस्तृत रूप से बढ़ाने में
11:01मुश्किल होते हैं और ये ग्राहक को देरी
11:07से भी दिए जाते हैं । यह हार्डवेयर के
11:13विपरीत है जहां आपको हार्डवेयर जल्दी
11:17विकसित करके दिया जाता है।
11:20तो, आइए देखें कि संकट के बाद यह क्या है,
11:27इसके कारण क्या हैं, और इसे कैसे दूर किया
11:34जाए?
11:35यदि हम सभी परियोजनाओं की स्टैंडिश समूह
11:39रिपोर्ट को देखें तो हर तीसरा प्रोजेक्ट
11:44सफल है, हम कह सकते हैं कि दुनिया भर
11:51में लगभग सभी परियोजनाओं की सफलता लगभग 30 प्रतिशत
11:57है।
11:58और, लगभग 20 प्रतिशत एकमुश्त विफलता है,
12:03उस परियोजना से कुछ भी नहीं निकलता है।
12:08और, लगभग आधी चुनौतीपूर्ण परियोजनाएं हैं,
12:13जो लागत में वृद्धि, खराब गुणवत्ता और
12:17आदि हैं।
12:19आइए देखें कि इस तरह के निराशाजनक आंकड़े
12:24के पीछे क्या कारण है, कि केवल एक तिहाई
12:31परियोजनाएं सफल होती हैं और 20 प्रतिशत
12:36असफलता इत्यादि।
12:37यदि हम अभी के परिदृश्य को देखें, तो हम देख
12:44सकते हैं कि कंपनियां हार्डवेयर पर जितनी
12:49राशि खर्च करती हैं, और जितनी राशि वे
12:55सॉफ्टवेयर पर खर्च करती हैं, यह अनुपात
13:00में बहुत कम हो जाता है।
13:04इसका मतलब यह है कि कंपनियां हार्डवेयर
13:09पर कम और सॉफ़्टवेयर पर खर्च कर रही हैं
13:15या दूसरे शब्दों में सॉफ़्टवेयर लागत,
13:19हार्डवेयर लागत की तुलना में बहुत तेज़ी
13:24से बढ़ रही हैं।
13:27कंपनियां अपने बजट का एक बड़ा हिस्सा
13:32आईटी सॉफ्टवेयर पर में खर्च करती हैं,
13:37एक उदाहरण स्वरुप, सॉफ्टवेयर लागत डेस्कटॉप
13:41या लैपटॉप पर देखने की तुलना में बहुत
13:47अधिक है, अगर आप इसे बाजार से खरीदते
13:53हैं।
13:54हार्डवेयर,ऑपरेटिंग सिस्टम के साथ 45,000
13:57में आता है।
13:59तो, मूल रूप से वास्तविक हार्डवेयर, तुलना
14:04में बहुत कम का होगा।
14:07लेकिन, फिर आप लैपटॉप या डेस्कटॉप को लेते
14:13हैं और हम मानते है कि आप उस पर कुछ सॉफ्टवेयर
14:21विकास कार्य करना चाहते हैं और आप एक
14:26केस टूल खरीदते हैं।
14:29यदि, आप एक तर्कसंगत सूट नोड लॉक खरीदते
14:35हैं तो इसकी कीमत 3,00,000 होगी।
14:39तो बस इस पर गौर करें कि लैपटॉप या डेस्कटॉप
14:46के लिए हार्डवेयर 45,000 का बहुत कम है,
14:52क्योंकि 45,000 में सॉफ़्टवेयर ऑपरेटिंग सिस्टम
14:56और भी शामिल है।
14:59और उस पर आप सॉफ्टवेयर डेवलपमेंट टूल चलाना
15:04चाहते हैं, जिसकी कीमत लगभग 3,00,000 है,
15:09जो कि एक नोड है जिसे एक फ्लोटिंग लाइसेंस
15:16लॉक किया जाता है।
15:19तो, बस इस विडंबना को देखिए कि आप इतनी
15:25कम कीमत में हार्डवेयर खरीदते हैं और जिस
15:30सॉफ्टवेयर पर आप इसे चलाते हैं, उसका
15:35सिर्फ एक उदाहरण कई सॉफ्टवेयर हैं,
15:40जिन्हें आपको खरीदना पड़ सकता है।
15:44तो, ऐसा लगता है, सॉफ्टवेयर बहुत महंगा शामिल
15:49है।
15:50और इसके तुलना में हार्डवेयर की लागत
15:55लगभग नगण्य हो जाएगी।
15:58जल्द ही ऐसी परिस्थिति आनेवाली है की आप
16:04सॉफ़्टवेयर खरीदते हैं और हार्डवेयर
16:07इसके साथ फ्री आता है, या कि आप सॉफ़्टवेयर
16:13खरीदते हैं और यह हार्डवेयर पर पहले
16:18से लोड हो आता है।
16:22हार्डवेयर मूल रूप से मुक्त है, लेकिन
16:27फिर यह समस्या क्या है जो यह पैदा कर रही
16:34है।
16:35लेकिन, इससे पहले कि यह देखें कि यदि
16:40हार्डवेयर इतनी अच्छी चीज है, जिसकी लागत
16:45बहुत कम होती है, और हमने कहा कि हार्डवेयर
16:51की लागत सॉफ्टवेयर तुलना में लगभग नगण्य
16:56है।
16:57फिर, केवल हार्डवेयर सिस्टम पूरी तरह
17:01से हार्डवेयर सिस्टम क्यों नहीं है?
17:06क्योंकि, कुछ भी जो सॉफ्टवेयर पर चल
17:11सकता है, कुछ भी जो हम सॉफ्टवेयर के
17:16साथ कर सकते हैं, हम हार्डवेयर के साथ
17:22भी कर सकते हैं, हम जो भी सॉफ्टवेयर
17:27में कर रहे थे उसे करने के लिए हम हार्डवेयर
17:34डिजाइन कर सकते हैं।
17:37उदाहरण के लिए, हम एक कहते हैं वर्ड
17:43प्रोसेसिंग सॉफ्टवेयर।
17:44हमारे पास एक छोटा हार्डवेयर घटक , जो
17:49पूरी तरह से हार्डवेयर हो, भी हो सकता है
17:56, जो वर्ड प्रोसेसिंग भी कर सकता है।
18:01आइए हम इस बहुत ही बेसिक प्रश्न का
18:06उत्तर दें, कि क्यों न एक पूरी तरह से हार्डवेयर
18:13प्रणाली हो, सॉफ्टवेयर से छुटकारा पाएं,
18:17यह समस्याग्रस्त है, बहुत सारे बग्स
18:22हैं, बहुत देर से मिलता है।
18:26लेकिन सॉफ्टवेयर के कुछ गुण हैं और
18:31इसी के कारण हर कोई सॉफ्टवेयर का उपयोग
18:36कर रहा है, अन्यथा पूरी तरह से हार्डवेयर
18:42सिस्टम होगा।
18:44आइए हम सॉफ्टवेयर के गुणों को देखें
18:48जिसकी वजह से पूरी तरह से हार्डवेयर
18:53सिस्टम होने के बजाय सॉफ्टवेयर ग्राहकों
18:58द्वारा पसंद किया जाता है।
19:01पहला अच्छा परिवर्तन करना अपेक्षाकृत
19:05आसान है, आप अतिरिक्त कार्यक्षमता जोड़ना
19:09चाहते हैं, किसी कार्यक्षमता को संशोधित करना
19:14चाहते हैं, तो अगला संस्करण जल्दी से
19:19आ जाता है ,आप अपना अनुरोध दे सकते हैं
19:25ताकि और एक पैच आपको भेज सकें।
19:30इसलिए, सॉफ़्टवेयर को बदलना बहुत आसान
19:34है बस एक कोड परिवर्तन करें, पुन: व्यवस्थित
19:40करें और यह हो जाता है।
19:44दूसरा बड़ा फायदा यह है कि इसमें कोई
19:50जगह नहीं लगती है, इसका कोई वजन नहीं
19:55होता है या आंतरिक रूप से इसमें सॉफ्टवेयर
20:01से जुड़ी कोई शक्ति नहीं है।
20:05ज़रा सोचिए कि, यदि आप एक वर्ड प्रोसेसिंग
20:11सॉफ्टवेयर चला रहे हैं, या क्षमा करें
20:16कि आप कुछ वर्ड प्रोसेसिंग कर रहे थे और, फिर
20:23आपने वर्ड प्रोसेसिंग के लिए हार्डवेयर
20:27विकसित किया, फिर आप एक एक्सेल चाहते
20:32थे और आपको इसके लिए एक और हार्डवेयर
20:38प्राप्त करना था।
20:40और, आप एक इमेज में एडिटिंग करना चाहते
20:45है क्षमा करे आप इमेज एडिटिंग करने की
20:51सॉफ्टवेयर कार्यक्षमता चाहते हैं और आपके
20:55पास हार्डवेयर का एक और टुकड़ा था और
21:01धीरे-धीरे आपका हार्डवेयर न केवल पूरे कमरे
21:06के स्थान पर कब्जा कर लेगा, बल्कि इन
21:11सभी का वजन और कल्पना शक्ति की खपत भी होगी
21:18और यह हार्डवेयर के लिए एक बड़ा नुकसान
21:24है।
21:25लेकिन, सॉफ्टवेयर बहुत जटिल कार्यक्षमता
21:28के लिए भी, जहां हार्डवेयर बहुत बड़ा होगा, यह
21:35हार्डवेयर की तरह कोई जगह, वजन या आंतरिक
21:40शक्ति नहीं रखता है, इसे चलने के लिए।
21:46और, यही कारण है कि सॉफ्टवेयर हमारे
21:51जीवन में अधिक से अधिक महत्वपूर्ण
21:55होता जा रहा है, सॉफ्टवेयर द्वारा हार्डवेयर
22:00पर अधिक से अधिक कार्यक्षमताएं लागू हो रही हैं।
22:06तो, एक बुनियादी हार्डवेयर है जिस पर हमारी सभी
22:13नई कार्यक्षमताएं जो आवश्यक हैं, सॉफ्टवेयर
22:17द्वारा विकसित की जाती हैं।
22:20अब, आइए हम सॉफ्टवेयर की कुछ विशेषताओं
22:25को देखें जो हमारे बाद की चर्चाओं के
22:31लिए बहुत महत्वपूर्ण हैं।
22:34कई विशेषताएं हैं, लेकिन हमने केवल
22:38दो विशेषताओं को ही चुना है; एक यह
22:44है कि, सॉफ्टवेयर जितना अधिक जटिल
22:48है, जितना अधिक कठिन हैं, उसे बदलना उतना
22:54ही कठिन है, ऐसा क्यों है?
22:58यह कारण बताना ज्यादा दूर नहीं है । सॉफ्टवेयर
23:03को बदलने में सक्षम होने के लिए हमें
23:09पहले सॉफ्टवेयर को समझना चाहिए, हमें
23:13पहले यह समझना चाहिए कि बदलाव कहां करना
23:19है, किन वेरिएबल्स (variables) को बदलना है,
23:24उसके लिए क्या कोड(code) लिखना है आदि।
23:29एक सॉफ़्टवेयर (software) जितना अधिक जटिल
23:33है, सॉफ़्टवेयर को समझने और यह पता लगाने
23:39के लिए उतना ही अधिक समय का प्रयास आवश्यक
23:45है कि वास्तव में कहां और क्या परिवर्तन
23:51होने की आवश्यकता है।
23:53दूसरी बात यह है कि जितनी बार हम एक सॉफ्टवेयर
24:01में बदलाव करते हैं, उतना ही अधिक यह जटिलता
24:07बन जाता है।
24:09हर बार जब हम किसी सॉफ़्टवेयर को बदलते
24:15हैं तो बदलाव की आवश्यकता विभिन्न कारणों से
24:20हो सकती है, हो सकता है कि बग को ठीक करना
24:28हो, हो सकता है कि कार्यक्षमता को बढ़ाना
24:34हो, हो सकता है कि यह एक बेहतर प्रदर्शन
24:40के लिए हो इत्यादि।
24:43ऐसे 100 कारण हो सकते है कि किसी विशिष्ट
24:49सॉफ़्टवेयर को बदलने की आवश्यकता क्यों
24:53है, और प्रत्येक परिवर्तन के लिए, सॉफ़्टवेयर
24:58अधिक जटिल हो जाता है।
25:02ऐसा क्यों है, इसका कारण यह है कि छोटे
25:08परिवर्तन होते हैं।
25:10उदाहरण के लिए, बग फिक्स का उदाहरण
25:15लेते है छोटे कार्यात्मकता (functionalities) आदि जोड़ने
25:20के लिए, हम सॉफ्टवेयर में सिर्फ तदर्थ
25:25परिवर्तन करते हैं।
25:27प्रारंभिक सॉफ़्टवेयर को एक अच्छे डिज़ाइन
25:31वगैरह के साथ विकसित किया जाता है, लेकिन
25:37प्रत्येक छोटा परिवर्तन बिगड़ता है या डिज़ाइन
25:42को और खराब कर देता है, इन्हें छोटे फिक्स
25:48के रूप में विकसित किया जाता है।
25:53और, इसलिए, ये सॉफ़्टवेयर को और अधिक जटिल बनाते
26:00हैं, समझने में अधिक कठिन, और बदलने के
26:05लिए इसी तरह।
26:07और अधिक कठिन |
26:09अब, हम इस मूल प्रश्न पर गौर करते हैं कि
26:16हम इस व्याख्यान में जिस बात को संबोधित
26:22करने का प्रयास कर रहे हैं, वह यह है
26:28कि सॉफ्टवेयर संकट(crisis) के पीछे क्या कारण
26:33है?
26:34हमने सॉफ्टवेयर संकट(crisis) को लक्षणों के रूप
26:39में कहा, जो कि खराब गुणवत्ता वाले सॉफ़्टवेयर,
26:45विलंबित परियोजनाओं, परियोजना की विफलता
26:48और पर दिखाई देते हैं।
26:52कई कारण हैं जो सॉफ़्टवेयर संकट(crisis) में योगदान
26:57करते हैं; पहली बड़ी समस्या है।
27:02अब, सॉफ़्टवेयर में बड़ी संख्या में
27:06फ़ंक्शंस हैं।100 या 1000 से अधिक कार्यात्मकताएं
27:11(functionalities) या 10 से 1000 से अधिक कार्यात्मकताएं
27:16प्रकार की कार्यक्षमताएं (functionalities) सरल सॉफ्टवेयर
27:21पैकेज के लिए भी आवश्यक है।
27:25खराब परियोजना प्रबंधन; परियोजना प्रबंधन
27:28चिंता का एक क्षेत्र है क्योंकि कई परियोजनाएं
27:34एक उचित परियोजना प्रबंधक के बिना
27:38और उचित परियोजना प्रबंधन कौशल के
27:42बिना विकसित होती हैं।
27:45और, यह सॉफ्टवेयर संकट(crisis) के प्रमुख
27:49कारणों में से एक होता है, क्यों परियोजनाएं
27:55इतने देर से वितरित नहीं हो पाती हैं
28:01इत्यादि । तीसरा बिंदु सॉफ्टवेयर
28:04इंजीनियरिंग में पर्याप्त प्रशिक्षण
28:06का अभाव है।
28:08डेवलपर्स कुछ डोमेन ज्ञान के साथ सॉफ्टवेयर
28:13विकसित (develop) करना शुरू करते हैं, लेकिन
28:18फिर वे सॉफ्टवेयर इंजीनियरिंग के मुद्दों
28:23की डिजाइन आवश्यकताओं, विनिर्देश, परीक्षण,
28:26परिवर्तन प्रबंधन आदि कि अनदेखी करते
28:30हैं।
28:31आधे प्रोजेक्ट (project) में स्किल की कमी
28:36को बढ़ाने के लिए मैनपावर टर्नओवर
28:40(manpower turnover), आधे प्रोजेक्ट (project) में कई प्रमुख
28:46व्यक्ति प्रोजेक्ट छोड़ देते हैं, यह
28:50काफी सामान्य है और इससे प्रोजेक्ट
28:54में देरी होती है।
28:57और, उत्पादकता में कम सुधार भी अन्य
29:02कारण है।
29:03बड़े पैमाने वाले सॉफ्टवेयर में भी
29:08मैन्युअल कार्य रह जाता है, सब कुछ ऑटोमेशन
29:13ऑटोमेटेड टूल्स ( automation automated tools ) इत्यादि होने
29:17पर भी।
29:18अभी भी बहुत सारे कोड को मैन्युअल
29:19रूप से लिखने की आवश्यकता है, बहुत सारे परीक्षण
29:20मैन्युअल रूप से और इसी तरह किए जाने
29:21चाहिए।
29:22लेकिन, तो आइए एक और बहुत ही बुनियादी
29:23प्रश्न को समझते हैं, कि किस तरह से
29:24सॉफ्टवेयर प्रोजेक्ट प्रबंधन अन्य इंजीनियरिंग
29:25परियोजनाओं के प्रबंधन से अलग है।
29:26मुझे केवल यह दोहराने दें कि सॉफ्टवेयर
29:27प्रोजेक्ट प्रबंधन और अन्य प्रोजेक्ट्स
29:28गैर सॉफ्टवेयर प्रोजेक्ट्स के प्रबंधन में मुख्य
29:29अंतर क्या है?
29:30पहली समस्या यह है कि सॉफ्टवेयर अमूर्त
29:31है।
29:32आप सॉफ्टवेयर को तब तक नहीं देखते
29:33हैं जब तक आप यह नहीं देखते हैं कि यह पूरा
29:34हो चुका है और चल रहा है, तभी आप देखते हैं
29:35कि स्क्रीन प्रदर्शित हो रहे हैं यह कुछ
29:36करता है, लेकिन जब तक ऐसा नहीं होता,
29:37यह सिर्फ दस्तावेजों का एक सेट या कोड के
29:38कुछ टुकड़े हैं, आप केवल दस्तावेजों
29:39या कोड को देखकर कितना शेष है यह नहीं समझ
29:40सकते।
29:41हो सकता है कि भारी मात्रा में कोड लिखा
29:42गया हो, लेकिन तब भी सॉफ्टवेयर पूरा होना
29:43बहुत दूर होता है, क्योंकि कई बग्स
29:44को ठीक करने की आवश्यकता होती है और इसे परीक्षण
29:45करने की आवश्यकता होती है।
29:46मुश्किल यह है कि, जो हम देख नहीं पा
29:47रहे हैं वह प्रबंधित करना भी मुश्किल
29:48है?
29:49उदाहरण के लिए, एक बड़े भवन का निर्माण,
29:50यहाँ परियोजना प्रबंधक अनुमान लगा सकता
29:51है कि भवन के निर्माण में कितना समय लग
29:52सकता है, शायद ६ महीने।
29:53विशाल भवन 6 महीने में, और तब वह देख
29:54सकता है कि भवन ऊपर आ रहा है, बाहरी भाग
29:55पूरा हो गया है, आंतरिक ज़रूरतों को पूरा
29:56करना है और इसी तरह।
29:57किसी भी समय वह सटीक रूप से बता सकता है
29:58कि कितना काम शेष है, लेकिन सॉफ्टवेयर
29:59में ऐसा नहीं है।
30:00दूसरी समस्या परिवर्तन प्रभाव है।
30:01एक इमारत में आप छोटे परिवर्तन करते हैं,
30:02आइये हम इसे निर्माण परियोजना कहते हैं।
30:03आप जानते हैं कि, वास्तव में इसका क्या प्रभाव
30:04पड़ेगा और आप अनुमान लगा सकते हैं और छोटे
30:05बदलाव कर सकते हैं जिनकी आवश्यकता हो
30:06सकती है।
30:07लेकिन दूसरी तरफ और सॉफ्टवेयर बेहद
30:08जटिल है, आप कुछ बदलते हैं, आप कुछ बदलने
30:09की कोशिश करते हैं और आप देखते हैं कि
30:10कई अन्य चीजें गलत तरीके से काम कर रही
30:11हैं या काम नहीं कर रही हैं।
30:12इसलिए, परिवर्तन का प्रभाव अन्य परियोजनाओं
30:13के मामले में पहचानना बहुत आसान है, लेकिन
30:14एक सॉफ्टवेयर परियोजना में यह इतना जटिल
30:15है कि आप अनुमान नहीं लगा सकते कि परिवर्तनों
30:16का प्रभाव क्या होगा?
30:17लेकिन, दुर्भाग्य से सॉफ्टवेयर को
30:18तेजी से बदलने की आवश्यकता है।
30:19और, जो हमने कहा कि यह सॉफ्टवेयर के
30:20उन फायदों में से एक है कि आप इसे जल्दी
30:21से बदल सकते हैं।
30:22और, इसलिए, हार्डवेयर की तुलना में सॉफ़्टवेयर
30:23में परिवर्तन का अनुरोध लाखों गुना
30:24अधिक होते हैं, जब आप एक हार्डवेयर
30:25विकसित कर रहे होते हैं आप परिवर्तन
30:26अनुरोध देने से पहले दो बार सोचते हैं।
30:27क्योंकि, हार्डवेयर में शामिल करने के
30:28लिए यह बहुत कठिन होगा, इसे पूरी तरह
30:29से फिर से तैयार करना होगा।
30:30जबकि, हर कोई जानता है कि सॉफ्टवेयर
30:31को बदला जा सकता है और इसलिए, बहुत सारे
30:32परिवर्तन अनुरोध आते हैं।
30:33तीसरी समस्या यह है कि सॉफ्टवेयर
30:34परियोजनाएँ बौद्धिक कार्य हैं।
30:35एक भवन निर्माण की तुलना में, जहाँ ईंटों
30:36को रखना पड़ता है, छत का निर्माण करना
30:37पड़ता है, चारदीवारी का निर्माण करना
30:38पड़ता है, रंग-रोगन करना पड़ता है।
30:39ये सभी बड़े पैमाने पर मैनुअल काम हैं
30:40और मैन्युअल काम का अनुमान लगाना
30:41आसान है, आप आसानी से पता लगा सकते हैं
30:42कि एक चित्रकार प्रति दिन कितना पेंट कर
30:43सकता है या एक मजदूर प्रति दिन ईंटों
30:44को रख सकता है इत्यादि ।
30:45जबकि, सॉफ्टवेयर एक बौद्धिक कार्य
30:46है।
30:47यह अनुमान लगाना बहुत मुश्किल है
30:48कि कोई व्यक्ति जो काम कर रहा है उसकी
30:49जटिलता क्या है और वह कितना पूरा कर
30:50पाएगा।
30:51तो, ये अन्य परियोजनाओं और सॉफ्टवेयर परियोजनाओं
30:52के बीच तीन मुख्य अंतर हैं।
30:53पहली बात यह है कि आपको कुछ प्रबंधित
30:54करना होगा, जो अदृश्य है।
30:55और, जो कुछ भी अदृश्य है उसे प्रबंधित
30:56करना मुश्किल है।
30:57दूसरी बात यह है कि सॉफ्टवेयर प्रोजेक्ट्स
30:58में बदलाव बहुत बार होते हैं, लेकिन तब
30:59परिवर्तन प्रभाव का अनुमान लगाना
31:00भी बहुत मुश्किल होता है, परिवर्तन
31:01प्रभाव आमतौर पर बहुत बड़ा होता है
31:02और अनुमान लगाना भी मुश्किल होता
31:03है।
31:04तीसरी बात यह है कि, हमें सॉफ्टवेयर परियोजना
31:05प्रबंधन में; हमें बौद्धिक कार्यों
31:06का प्रबंधन करना होगा।
31:07यह मैनुअल काम के प्रबंधन की तुलना
31:08में बहुत बड़ी समस्या है।
31:09मैनुअल काम में हम आसानी से अनुमान
31:10लगा सकते हैं, एक दिन में कितना नीचे आ
31:11सकता है, समस्या की जटिलता क्या है और
31:12इसी तरह।
31:13बौद्धिक कार्यों में हम न तो अनुमान
31:14लगा सकते हैं कि कार्य की जटिलता क्या है
31:15और न ही इसके लिए कितना प्रयास करना होगा।
31:16और, हमें इस सवाल पर आते है, कि सॉफ्टवेयर
31:17परियोजना प्रबंधन कठिन है जैसा कि हमने
31:18पिछली चर्चा से अनुमान लगाया है।
31:19यह अन्य प्रकार की परियोजनाओं के प्रबंधन
31:20की तुलना में बहुत कठिन है।
31:21सॉफ़्टवेयर अदृश्य है और ऐसी किसी चीज़
31:22का प्रबंधन करना कठिन है जिसे आप देख
31:23नहीं सकते हैं, यह बौद्धिक और जटिल
31:24कार्य का प्रबंधन है, ग्राहकों की आवश्यकताओं
31:25को बदलना अपवाद के बजाय नियम है, और जनशक्ति
31:26का कारोबार भी है।
31:27आप किसी प्रोजेक्ट पर प्रोजेक्ट मैनेजर
31:28हो सकते हैं, लेकिन फिर आपको पता चलता
31:29है कि आपके कुछ महत्वपूर्ण डेवलपर्स, वे प्रोजेक्ट
31:30छोड़ देते हैं।
31:31और, उन्होंने जो विकसित किया है उनके पास
31:32वह डोमेन (Domain) ज्ञान है, और एक बार उनके
31:33छोड़ने के बाद किसी अन्य व्यक्ति को
31:34प्राप्त करना बहुत मुश्किल हो जाता
31:35है जो उनके काम को समझेगा और उस बिंदु
31:36से विकसित करना शुरू कर देगा।
31:37ये एक बड़ी समस्या है जो एक सॉफ्टवेयर
31:38प्रोजेक्ट मैनेजर को झेलनी पड़ती है।
31:39लेकिन, फिर यहां कई अन्य छोटी समस्याएं
31:40हैं जिन्हें हमने सूचीबद्ध नहीं किया
31:41है।
31:42लेकिन, इससे पहले कि हम आगे, बढ़ने से
31:43पहले चर्चा करना पसंद करते हैं, हम
31:44चर्चा करना पसंद करते हैं कि परियोजनाएं
31:45क्या हैं?
31:46यह कार्यों और अन्वेषण से कैसे अलग है?
31:47टास्क दिनचर्या के काम हैं, उदाहरण के
31:48लिए,आइए हम एक मूवी टिकट खरीदें या एक
31:49वीडियो व्याख्यान देखें।
31:50ये टास्क है या कार्य हैं, ये बहुत ही कम
31:51अनिश्चितता के साथ अच्छी तरह से परिभाषित
31:52और समझी गई गतिविधि की पुनरावृत्ति हैं,
31:53हाँ एक व्याख्यान को देखने के लिए , आपको
31:54वहां बैठना होगा और देखते हुए यह पता
31:55है कि आपको आधे घंटे बैठना है, जबकि, दूसरे
31:56ओर आपको अन्वेषण है जहां परिणाम बहुत
31:57अनिश्चित है, पर किया जा सकता है।
31:58उदाहरण के लिए, कैंसर का इलाज खोजना या
31:59ग्लोबल वार्मिंग का हल खोजना।
32:00तो, ये अन्वेषण हैं, और परिणाम अनिश्चितत
32:01है, आप कभी नहीं जानते कि आपके काम में सफलता
32:02होगी या नहीं।
32:03परियोजनाये बीच में हैं, परियोजनाओं
32:04में चुनौती है, और साथ ही कुछ नियमित
32:05कार्य शामिल हैं।
32:06और, यही कारण है कि यहां परियोजना प्रबंधन
32:07महत्वपूर्ण है, क्योंकि कार्यों या अन्वेषण
32:08के लिए आपको परियोजना प्रबंधन की आवश्यकता
32:09नहीं है।
32:10ये विशुद्ध रूप से नया काम हैं जबकि,
32:11परियोजनाएं वह हैं जहां आपको परियोजना
32:12प्रबंधन की आवश्यकता होती है जो यहां महत्वपूर्ण
32:13बात है, इस परिचयात्मक चर्चा के साथ, हम यहां
32:14रुकेंगे और अगले व्याख्यान में इस
32:15बिंदु से जारी रखेंगे।
32:16धन्यवाद।

About this transcript

This page contains the full transcript of Lecture 01: Introduction - I by NPTEL IIT Kharagpur, generated from the public captions YouTube serves with the video. The transcript has 3,206 words across 486 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.