YT YouTube2Text

YouTube2Text → Transcripts → Lecture 17: Project Estimation Techniques (Contd.)

Lecture 17: Project Estimation Techniques (Contd.) — Transcript

by NPTEL IIT Kharagpur · 5,425 words · 729 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:09यहाँ विभिन्न एस्टिमॅटिंग मेथड्स (estimating methods) है,
0:13तो अब हम एस्टिमेशन (estimation) के बारे में
0:19देखेंगे।
0:20तो, आइए हम एक प्रकार के वर्गीकरण को देखते
0:25हैं, जो मौजूदा एस्टिमॅटिंग मेथड्स (estimating methods) का
0:30एक वर्गीकरण है। एस्टिमेशन (Estimation)ऊपर
0:34या नीचे ऊपर हो सकता है। वे नोर्मल्ली
0:39(Normally )एक्टिविटी बेस्ड (activity based) और एनालिटिकल
0:44(analytical) होते हैं। एस्टिमेशन टेक्निक्स (estimation techniques)
0:48पैरामीट्रिक (parametric) या एल्गोरिथ्म मॉडल
0:51(algorithm models) हो सकती है, एक उदाहरण के लिए
0:57फ़ंक्शन पॉइंट्स (function points) है जो हम अगली
1:03कक्षा में देखेंगे। फिर एक्सपर्ट जजमेंट
1:06तकनीक (expert Judgement technique), जो की एक्सपर्ट जजमेंट
1:12(expert Judgement) की एक और श्रेणी है। यहाँ, हम विभिन्न
1:18एस्टिमेट्स (estimates) का अनुमान लगाते
1:22हैं, प्रारंभिक अनुमान के साथ हम एस्टिमेशन
1:26प्रोसीजर (estimation procedure) शुरू करते हैं। फिर
1:31इसके नाम के अनुरूप, हमें यह देखना होगा
1:36कि एक प्रोजेक्ट (Project) किस के अनुरूप
1:41है। यह प्रोजेक्ट (Project) एक अन्य मौजूदा
1:45प्रोजेक्ट (Project) के समान है, फिर हम आवश्यक
1:50पैरामीटर्स (Parameters)का एस्टिमेट्स (estimates)
1:53लगा सकते हैं। ये सामान्य रूप से
1:58केस(case)- बेस्ड (based )हैं और यह कम्पेरेटिव
2:02प्रिंसिपल (comparative principle) पर बेस्ड (based )है और
2:07एस्टिमेशन (estimation) के लिए एक और मेथोडोलोग्य
2:12(methodology) प्राइस टू विन (price to win) होती है।
2:18हम प्राइस टू विन (price to win) के साथ शुरू
2:24करते हैं, इसे क्या कहते हैं? प्रोजेक्ट
2:29(Project) की कॉस्ट (cost) जो भी ग्राहक उस पर खर्च
2:36कर सकता है। तो, इसके अनुसार कॉस्ट (Cost)या
2:41एस्टिमेटेड प्रोजेक्ट कॉस्ट (estimated project cost ) वह
2:45कॉस्ट (Cost)है जो ग्राहक उस पर खर्च कर सकता
2:51है। तो, प्रोजेक्ट (Project) कॉस्ट (COST) जो भी
2:57ग्राहक प्रोजेक्ट (Project) पर खर्च कर सकते
3:01हैं और यहाँ लाभ यह है कि आप कॉन्ट्रैक्ट
3:07(Contract) प्राप्त कर सकते हैं, यह बहुत संभावना
3:12है कि आप कॉन्ट्रैक्ट (Contract) प्राप्त करेंगे
3:17और नुकसान यह है कि वे आवश्यक रूप से
3:23आवश्यक कार्य को रिफ्लेक्ट (reflect) नहीं
3:27करते हैं। तो, क्या काम किया
3:31जाएगा कॉस्ट (COST) सही ढंग से आवश्यक कार्य
3:36को रिफ्लेक्ट (reflect) नहीं कर सकती है।
3:40इसलिए, यहां या तो ग्राहक को देसिरद
3:45सिस्टम (desired system) नहीं मिलेगा या ग्राहक
3:50के पास क्या होगा, जो ओवरपे (Overpay) कर देगा,
3:56क्योंकि काम कम है और वह उस काम के संबंध
4:02में देसिरद (Desired) से अधिक भुगतान कर सकता
4:07है जो उसे या उस सर्विस (Service) से मिल रहा है।
4:15तो, यह एप्रोच (approach) बहुत ही अनएथिकल
4:19(unethical)और असहनीय हो सकती है, क्योंकि
4:23जैसा कि आपने देखा है कि कॉस्ट (COST)आवश्यक
4:28कार्य की मात्रा को सही ढंग से रिफ्लेक्ट
4:34(reflect) नहीं करती हैं। तो, यह अनुमान लग सकता
4:39है कि यह अनएथिकल (unethical)और असहनीय है;
4:44हालाँकि, जब कार्य की मात्रा आदि के
4:49बारे में विस्तृत जानकारी की कमी है,
4:53तो यह विधि एकमात्र उपयुक्त स्ट्रेटेजी
4:57(strategy) हो सकती है। तो, अब, देखते हैं कि सबसे
5:04एथिकल एप्रोच (ethical approach) कौन सा है? प्रोजेक्ट
5:09(Project) की कॉस्ट (COST) एक आउटलाइन प्रपोजल
5:13(outline proposal ) के आधार पर सहमत है और डेवलपमेंट(development)
5:19उस कॉस्ट(cost) पर निर्भर है
5:23इसलिए, प्रोजेक्ट (Project) की कॉस्ट (COST) सामान्य
5:27रूप से होती है, यह डेवेलप्मवन्त (development)
5:32के आधार पर ग्राहक के बीच सहमति होती
5:37है इसलिए, प्रोजेक्ट (Project) की कॉस्ट (COST) सामान्य
5:42रूप से, इस डेवलपर (Developer) और ग्राहक के
5:48बीच इस बात पर सहमत होती है कि एक आउटलाइन
5:54प्रपोजल (outline proposal) के आधार पर क्या विकास
5:59उस कॉस्ट (COST) से बाधित होता है।
6:04तो, यह कि क्या एथिकल (ethical) होना चाहिए और
6:10एक डिटेल्ड स्पेसिफिकेशन (detailed specification) पर बातचीत
6:14की जा सकती है या सिस्टम विकास के लिए एक विकासवादी
6:22दृष्टिकोण का उपयोग किया जा सकता है।
6:26तो, प्रोजेक्ट प्लानिंग (project planning) के लिए किन
6:31पैरामीटर्स (parameters) का अनुमान लगाया
6:35जाना है? हमें एफर्ट (effort) का एस्टिमेशन
6:39(estimation) लगाने की आवश्यकता है या इंदिरेक्ट
6:44(indirect)रूप से कॉस्ट (COST) और अवधि है लेकिन
6:49प्रॉब्लम डिस्क्रिप्शन (problem description) से सीधे
6:53एफर्ट (effort) या कॉस्ट (COST) या अवधि का अनुमान
6:59लगाना बहुत मुश्किल है।तो, हमें क्या
7:03करना है? एफर्ट (effort) और अवधि,
7:07उन्हें प्रोजेक्ट (project) के आकार के संदर्भ
7:11में मापा जा सकता है, जो एक इंदिरेक्ट
7:17मीट्रिक (indirect metric) और एक प्रोजेक्ट (project)
7:21का आकार है जिसे हम LOC का उपयोग करके माप
7:28सकते हैं जो कि लाइन्स ऑफ़ कोड (Lines of Code) या FP
7:35है जो फंक्शन पॉइंट (Function Point) है।
7:39हम जानते हैं कि एफर्ट (effort) और कॉस्ट दरशण
7:44(cost duration) के रूप में सीधे अनुमान नहीं
7:49लगाया जा सकता है। हमें एक साइज (Size)का
7:53उपयोग करना है हाँ, हमें एस्टिमेशन (Estimation)
7:58लगाने के लिए , एफर्ट और दरशण (effort and duration)
8:03का आकलन करने क लिए ,प्रोजेक्ट साइज
8:08(Project size) का उपयोग करना होगा ,
8:12इसलिए, साइज (Size) काम का एक मौलिक उपाय
8:18है, इसके आधार पर हम एफर्ट और दरशण (effort
8:25and duration) जैसे अन्य पैरामीटर्स (parameters) का अनुमान लगा
8:29सकते हैं। तो, यह एस्टिमेटेड
8:32साइज (estimated size) ठीक है, एस्टिमेटेड साइज
8:36(estimated size) के आधार पर, दो पैरामीटर्स (parameters)
8:40का अनुमान लगाया जा सकता है; वे एफर्ट
8:45और दरशण (effort and duration) हैं।
8:48तो, इस एफर्ट (effort) को आम तौर पर पर्सन मंथ
8:54(person month) मे मापा जाता है, मैंने पहले ही
9:00आपको बता दिया है कि क्या वह पर्सन
9:05मंथ (person month) में मापा जाता है।पर्सन मंथ
9:10(person month) को कैसे परिभाषित किया जाता है? एक पर्सन
9:17मंथ (person month) को उस एफर्ट (effort) के रूप में परिभाषित
9:24किया जाता है जिसे एक व्यक्ति आमतौर
9:28पर एक महीने में कर सकता है।
9:32तो, एक पर्सन मंथ (person month) का मतलब वह एफर्ट
9:39(effort) है जिसे एक व्यक्ति आम तौर पर एक महीने
9:45में डाल सकता है। तो, इस तरह से हम इसकी
9:52गणना कर सकते हैं, हम किस व्यक्ति को
9:57पर्सन मंथ (person month) के रूप में परिभाषित
10:02कर सकते हैं और पर्सन मंथ (person month) का उपयोग
10:08करके, हम एफर्ट (effort) को माप सकते हैं।
10:13इसलिए, जैसा कि मैंने आपको पहले ही बताया
10:18है, हमें साइज (Size) की गणना करनी होगी तब
10:24हम एफर्ट (effort) और डुएराशन (Duration) की गणना कर सकते
10:30हैं।
10:31तो, साइज (Size) क्या है?यह काम का एक उपाय है
10:37जो किया जा रहा है। तो, प्रोजेक्ट (Project)
10:42का साइज (Size) प्रॉब्लम कम्प्लेक्सिटी (problem
10:46complexity) का एक उपाय है ,ठीक है। प्रोजेक्ट
10:51साइज (Project Size) को समस्या की कम्प्लेक्सिटी
10:56(complexity) का एक उपाय माना जा सकता है, किस संदर्भ
11:02में? एफर्ट (effort) और प्रोडक्ट (Product) को
11:07विकसित करने के लिए आवश्यक समय के संदर्भ
11:12में। प्रोजेक्ट साइज (Project Size) को मापने के
11:17लिए दो मैट्रिक्स (metrics) पॉपुलर (popular) हैं।
11:21मैं आपको पहले ही बता चुका हूं कि LOC
11:27है या एक शब्दों में कह सकते हैं कि सोर्स
11:33लाइन्स ऑफ़ कोड (Source Lines of Code) या LOC और दूसरा
11:40फंक्शन प्वाइंट (Source Lines of Code) या FP है।
11:46तो, SLOC कन्सेप्तुअल्ली (conceptually) रूप से सरल
11:50है, बस कोड की पंक्तियों को काउंट (Count) करना
11:56है, कोड (Code) की सोर्स लाइन्स (Source Line) को हमें
12:02काउंट (Count) करना है जो कन्सेप्तुअल्ली
12:06(conceptually) रूप से बहुत सरल है, लेकिन आजकल
12:11FP है, यह एक SLOC के पक्ष में है।
12:17हम देखेंगे कि SLOC की कई कमियां हैं। SLOC
12:23की कई कमियों के कारण आजकल लोग FP का उपयोग
12:29कर रहे हैं, यह LOC का पसंदीदा विकल्प है,
12:35हम कुछ मिनटों के बाद चर्चा करेंगे
12:39कि SLOC की कमियां क्या हैं।
12:43तो, कोड (Code) की पंक्तियों का मतलब है; कोड (Code)
12:50की एक पंक्ति क्या है? मूल रूप से, कोड
12:56(Code) की इन पंक्तियों को प्रोपोसड (proposed)
13:00किया गया था जब कार्ड (Card) के लिए एक लाइन
13:07के साथ कार्ड (Card) पर प्रोग्राम (Program) टाइप
13:12किए गए थे। इसलिए, पहले लोग पंच कार्ड
13:18का उपयोग कर रहे थे। इसलिए, उस समय के दौरान
13:24यह कोड की लाइनें प्रोपोसड की (proposed)
13:29थी। यह प्रोपोसड (proposed) किया गया था कि
13:34जब कार्ड (Card) पर प्रोग्राम टाइप किए गए हों हर
13:41कार्ड क लिए एक लाइन का पंच कार्ड (Punch card)
13:47हो | तो, क्या होता है जब जावा (Java) में
13:53स्टेटमेंट (Statement) कई लाइन या जहाँ एक पंक्ति
13:59में कई कथन हो सकते हैं; यह कोड की लाइनों
14:05की खामी है। तो, यह ध्यान में रखते हुए
14:11विकसित किया गया था कि कार्ड (Card) के
14:17लिए केवल एक लाइन दर्ज की जा सकती है।
14:23यह मीट्रिक मीनिंगफुल ( meaningful) था, लेकिन जब,
14:27विभिन्न प्रोग्रामिंग लैंग्वेज (programming language)
14:31उच्च स्तरीय प्रोग्रामिंग लैंग्वेज (high level programming
14:35languages) आईं और जावा जैसे कुछ मामलों में यह
14:41कथन हैं, जावा(Java) जो कई पंक्तियों में
14:45या एक पंक्ति में आप स्टेटमेंट्स (statements)
14:50को बढ़ा सकते हैं तब कोड (code) की यह पंक्तियाँ
14:56प्रोग्राम साइज (program size) को मापने के लिए
15:01उपयुक्त मीट्रिक (Metric) नहीं हो सकती
15:05हैं। इसलिए, इसी तरह के प्रोग्राम्स (programs)
15:09को सिस्टम (Sysytem) के हिस्से के रूप में
15:14गिना जाना चाहिए। तो, सिस्टम (system) के
15:19हिस्से के रूप में कौन से प्रोग्राम
15:23(program) गिना जाएगा उदाहरण के लिए, GUI।
15:27तो, यह एक फंक्शनल रेक्विरेमेंट (functional
15:31requirement) नहीं है, लेकिन यह GUI डिजाइन (Design) करने
15:37क लिए लिखा जाना चाहिए क्या इसे इस सिस्टम
15:42(system) के एक भाग के रूप में गिना जाना चाहिए।
15:49इसी तरह, बिल्ट-इन (built in) क्लासेज (classes)
15:53जो प्रोग्रामिंग लैंग्वेजेज (programming
15:56languages) में प्रदान की जाती हैं।
16:00तो, क्या उन्हें इस LOC के लायक गिना जा
16:04सकता है? क्या उन्हें उस सिस्टम (system) के
16:09भाग के रूप में गिना जाएगा जिसे आप विकसित
16:14करने जा रहे हैं? तो, ये कुछ सीमाएँ हैं,
16:19आप कह सकते हैं और यही वजह है कि कोड
16:25(Code) की लाइनें इन सभी मॉडर्न ऍप्लिकेशन्स
16:29(modern applications) के लिए उपयुक्त मीट्रिक (Metric) नहीं
16:33हो सकती हैं। प्रारंभ में, सॉफ्टवेयर डेवलपमेंट
16:37(software development) में केवल कोड (code) लिखना होता
16:42है, लेकिन अब, किसी भी सिस्टम (system) या
16:46प्रोजेक्ट (Project) को विकसित करते समय
16:50कई चीजें संभव होती हैं या कई चीजें होती
16:55हैं।
16:56इसलिए, कोड (Code) की पंक्तियों में हम LOC जैसे शब्दों
17:01का उपयोग करेंगे, जो कोड की पंक्तियों
17:05को रेप्रेसेंट्स (represents) करता है, KLOC कोड
17:09की कौन-सी किलो लाइन्स ऑफ़ कोड (kilo lines of code) को
17:15रेप्रेसेंट्स (represents) करती है, जिसका मतलब
17:19है कि हजारों लाइनें। KSLOC का अर्थ है कोड
17:24(code) की हजारों source line और NCKLKSLOC का अर्थ है
17:29नया या KSLOC परिवर्तन तो, कितने?
17:33लाइन्स ऑफ़ कोड (lines of code) क्या है ?वे पूरी
17:39तरह से नए हैं या उन्हें बदल दिया गया है।तो,
17:44ये टर्मिनोलॉजीज़ (terminologies) हैं, वे कोड(Code)
17:48के इस मीट्रिक (Metric) लाइनों में उपयोग
17:52किए जाते हैं।
17:53तो, अब हम कहते हैं कि कुछ चीजें LOC के
17:59मामले में काउंटर-इन्टुइटीवे (counter-intuitive) हैं।प्रोग्रामर
18:02(programmer) जितना अधिक प्रोडक्टिव (productive)
18:05होता है भाषा का स्तर उतना ही कम होता है;
18:10जाहिर है।तो, भाषा का स्तर कम है। उदाहरण
18:15के लिए; आप कहते हैं कि असेंबली लेवल
18:19लैंग्वेज (assembly level language), वगैरह, तो उनका साइज
18:24(Size) क्या होगा, यह कम होगा।
18:27एक प्रोग्रामर (programmer) के साथ एक इंस्ट्रक्शन
18:31(instruction) में कई चीजें हासिल हो सकती हैं।
18:36इसलिए, यही कारण है कि लैंग्वेज (language)
18:40का निचला स्तर अधिक प्रोडक्टिव (productive)
18:43है, प्रोग्रामर (programmer), केवल कम वाक्यों
18:47का उपयोग करके बहुत सी नौकरियों को प्राप्त
18:51कर सकते हैं। और इसी तरह, मैंने पहले ही
18:56आपको बताया है कि सेम फंक्शनलिटी (same
19:00functionality) लौ लेवल लैंग्वेज (low level language) में लागू
19:05करने के लिए अधिक कोड(Code) लेती है, फिर
19:10हाई लेवल लैंग्वेज (high level language) में यह नहीं
19:15है। सेम फंक्शनलिटी (same functionality) हाई लेवल
19:19लैंग्वेज (high level language) की तुलना में लौ लेवल
19:24लैंग्वेज (low level language) में लागू करने के
19:29लिए अधिक कोड (Code) लेती है। इसलिए, वर्बोस
19:33(verbose) जितनी अधिक होगी, प्रोडक्टिविटी (productivity)
19:37उतनी ही अधिक होगी।
19:39इसलिए, यदि अधिक वर्बोस (verbose) होगी तो अधिक
19:43वर्बोस (verbose) करने वाला प्रोग्रामर
19:46(Programmer) हायर प्रोडक्टिविटी (higher productivity)देगा। कोड(Code)
19:50की लाइनों के आधार पर प्रोडक्टिविटी
19:53(productivity) के उपाय प्रोग्रामर (Programmer) को सुझाव देते
19:58हैं जो वर्बोस (verbose) कोड (Code) लिखते हैं
20:02वे प्रोग्रामर (Programmer) की तुलना में अधिक
20:06प्रोडक्टिव (productive) होते हैं जो सिर्फ
20:09कॉम्पैक्ट कोड (compact code) लिखते हैं, क्योंकि
20:13वह अधिक उपयोग कर रहा है क्या वह वर्बोस
20:19(verbose) का उपयोग कर रहा है।तो, इसीलिए कोड
20:23की लाइनें अधिक होंगी। तो, यह कहता है कि
20:28कोड(Code) की तर्ज पर आधारित प्रोडक्टिविटी
20:32(productivity) को मापने का सुझाव है कि प्रोग्रामर
20:36(Programmer) जो वर्बोज़ कोड लिख रहे हैं, वे
20:41अधिक प्रोडक्टिव (productive) हैं और प्रोग्रामर
20:44(Programmer) की तुलना में, जो कॉम्पैक्ट कोड
20:48(compact code) लिखते हैं। तो, यह कोड (Code) की लाइनों
20:54के लिए एक और काउंटर इन्टुइटीवे (counter intuitive)
20:58है।
20:59अब, जल्दी से हम SLOC की कुछ प्रमुख कमियों
21:04को देखते है। साइज (Size) कोडिंग स्टाइल
21:08(coding style) के साथ भिन्न हो सकते हैं। इसलिए,
21:13विभिन्न प्रोग्रामर (Programmer) अलग-अलग कोडिंग
21:16स्टाइल (coding style) का पालन कर सकते हैं और यदि
21:21कोडिंग स्टाइल (coding style) अलग है, तो आकार
21:26अलग होगा।
21:27इसी तरह, LOC, यह केवल कोडन एक्टिविटी (coding
21:32activity) को केंद्रित करता है ,कोई अन्य
21:36गतिविधि नहीं है, क्योंकि आपको सॉफ़्टवेयर
21:39(Software) को विकसित करते समय, आपको रेक्विरेमेंट
21:43एनालिसिस (requirement analysis) करना होगा, आपको डिज़ाइन
21:47(Design) करना पड़ सकता है, आपको टेस्ट (Test)
21:52वगैरह करना पड़ सकता है, लेकिन इस LOC के
21:56लिए आप कुछ एफर्ट (effort) कर रहे हैं, रेक्विरेमेंट
22:01एनालिसिस (requirement analysis) के लिए या कोडिंग
22:04(Coding) के लिए या टेस्ट (Test) के लिए या डिजाइनिंग
22:09(Designing) के लिए आप कुछ एफर्ट (effort) कर रहे
22:13हैं, लेकिन LOC इस बात पर ध्यान नहीं देता
22:17है, यह केवल कोडिंग एक्टिविटी (coding activity)
22:20पर केंद्रित है यह कोड की क्वालिटी
22:23और एफिशिएंसी (quality and efficiency) के साथ बहुत
22:28खराब संबंध रखता है।
22:31तो, कोड की क्वालिटी और एफिशिएंसी (quality
22:36and efficiency) क्या होगी? तो, LOC उनके साथ बहुत
22:40खराब तरीके से करेलटेस (correlates) करता है, हायर
22:44लेवल प्रोग्रामिंग लैंग्वेज कोड (higher
22:47level programming language code) को दंडित करता है, पुन: उपयोग,
22:49वगैरह |यदि आप बहुत हायर लेवल प्रोग्रामिंग
22:50लैंग्वेज (higher level programming language) का उपयोग कर रहे
22:54हैं, क्योंकि अस्सेम्ब्ले लैंग्वेज प्रोग्रामिंग
22:57(assemble language programming) में बहुत ही कम स्टेटमेंट्स
23:01(Statements) के साथ काम किया जा सकता है, लेकिन
23:06हायर लेवल प्रोग्रामिंग लैंग्वेज (higher level programming
23:10language) में आप इसके लिए कुछ और कथनों का उपयोग
23:16कर सकते हैं। तो, यह हायर लेवल प्रोग्रामिंग
23:20लैंग्वेज (higher level programming language), प्रोग्रामिंग
23:23लैंग्वेज (programming language)को दंडित करता है।
23:27इसी तरह, यदि आप कोड (Code) का उपयोग कर रहे
23:32हैं, यदि आप इस कोड का पुन: उपयोग कर रहे
23:38हैं, इसका मतलब है, आपने एक बार और कोड
23:43(Code) को विकसित किया है और फिर से आप उपयोग
23:48कर रहे हैं। तो, फिर यह भी पेनलीजेस (penalizes)
23:53करेगा इसलिए साइज (Size) को सही ढंग से ठीक
23:58नहीं किया जा सकता है,यदि आप कोड का पुन:
24:03उपयोग कर रहे हैं। तो, ये SLOC की कुछ कमियाँ
24:09हैं।
24:10इसलिए, समस्या के वर्णन से प्रोजेक्ट
24:13(Project) की शुरुआत में अन्य कमियों का अनुमान
24:17लगाना मुश्किल है, अगर हमें SRS डॉक्यूमेंट
24:21(document) की तरह सिर्फ एक समस्या का विवरण
24:26दिया जाता है, तो यह अनुमान लगाना बहुत
24:30मुश्किल है, की बहुत शुरुआत मे प्रोजेक्ट
24:34(Project) की साइज (Size) क्या है। एकमात्र तरीका,
24:38आप शुरुआत में एक सटीक अनुमान नहीं
24:42लगा सकते हैं, अनुमान लगाने के लिए एकमात्र
24:47तरीका यह है कि अनुमान लगाया जाए और यह प्रोजेक्ट
24:52(Project) की योजना के लिए उपयोगी नहीं है।
24:57तो, इसीलिए यह LOC प्रोजेक्ट प्लानिंग (project planning)
25:01के लिए बहुत उपयोगी नहीं है। तो, मैं आपको
25:07पहले ही बता चुका हूं, इसका उपयोग केवल
25:12कोड मैसूर (code measure)के रूप में किया जाता
25:17है। इसका उपयोग उस एफर्ट
25:20(effort) को मापने के लिए नहीं किया जा सकता
25:26है जिसे आप अपनी रेक्विरेमेंट एनालिसिस (requirement analysis)
25:31या डिजाइन (Design) के दौरान डाल रहे हैं
25:36इसे मापने के लिए इसका टेस्टिंग (Testing)
25:40नहीं कि जा सकती है। इसी तरह, यह प्रोग्रामर
25:46(programmer) पर निर्भर है, क्योंकि विभिन्न
25:50प्रोग्रामर (programmer) प्रोग्राम (Program) को
25:53अलग तरीके से लिखेंगे। तो, लाइन्स ऑफ़ कोड
25:58(lines of code) बहुत भिन्न होते हैं, इसलिए यह
26:01प्रोग्रामर (programmer) पर निर्भर है और यह
26:04स्ट्रक्चरल या लॉजिकल कम्प्लेक्सिटी (structural
26:06or logical complexity) पर विचार नहीं करता है। यह
26:10केवल लेक्सिकल और टेक्सटुअल कम्प्लेक्सिटी
26:12(lexical and the textual complexity) पर ही विचार करता है,
26:17यह प्रोग्राम (Program) की स्ट्रक्चरल या
26:20लॉजिकल कम्प्लेक्सिटी (structural or logical complexity) पर
26:23विचार नहीं करता है।
26:26अभी भी LOC के साथ कुछ और कठिनाइयाँ हैं
26:28जैसे LOC प्रोग्रामिंग मेथोडोलोजिज़ प्रोग्राम
26:30(programming methodologies program) और लैंग्वेजेज और टूल्स
26:34(languages and tools) में तेजी से बदलाव के कारण
26:35अस्पष्ट हो सकती है। इसलिए, प्रोग्रामिंग
26:36मेथोडोलोजिज़ (programming methodologies), लैंग्वेजेज
26:37और टूल्स (languages and tools) में परिवर्तन के
26:38कारण, SLOC अस्पष्ट हो जाती है।
26:39लैंग्वेजेज (languages) की प्रगति देख सकते
26:40हैं। .
26:41इसलिए, अलग-अलग लैंग्वेजेज (languages) आ रही हैं और
26:42इससे समस्या हो सकती है, इससे SLOC का आकलन
26:43करते समय अस्पष्टता हो सकती है। इसी तरह,
26:45कई टूल्स (Tools) वहां हैं जहां आप ऑटोमेटिकली
26:47(automatically) सोर्स कोड (source code) उत्पन्न कर
26:49सकते हैं।
26:50तो, फिर क्या यह SLOC बहुत उपयोगी नहीं
26:51हो सकता है जैसे कि आप कह रहे हैं कि RSA
26:54रैशनल सॉफ्टवेयर आर्किटेक्ट (rational software
26:55architect) हैं जहां क्लास डायग्राम (class diagram) से
26:57आप ऑटोमेटिकली गेनेराते (automatically generate) रूप से
26:59स्केलेटल कोड (skeletal code) उत्पन्न कर सकते
27:01हैं, तब SLOC ठीक से नहीं हो सकता है कि यह क्या
27:04है, यह इसको मापने के लिए उपयुक्त नहीं
27:06हो सकता है कि साइज (Size) को मापने के लिए
27:08उपयुक्त मीट्रिक (Metric) नहीं हो सकता
27:10है, इसी तरह कस्टम सॉफ्टवेयर और रेउसे
27:12( custom,software and reuse) और पुन: उपयोग।
27:14यदि आप सॉफ़्टवेयर (Software) को कस्टमाइज़
27:17(Customize)कर रहे हैं, यदि आप एक अनुकूलित सॉफ़्टवेयर
27:21डेवेलोप(Customize software develop) कर रहे हैं और आप कोड
27:26का पुन: उपयोग कर रहे हैं तो SLOC अस्पष्ट
27:30हो सकता है और इसी तरह नए प्रोग्रामिंग
27:31(Programing )या प्रोग्रामिंग मेथोडोलॉजी(Programming
27:32Methodology) में परिवर्तन जैसे ऑब्जेक्ट ओरिएंटेड
27:33प्रोग्राम(Object oriented Program), आस्पेक्ट उन्मुख
27:34प्रोग्राम(aspect oriented programs), फीचर ओरिएंटेड
27:35प्रोग्राम(feature oriented Proram) भी SLOC, में है SLOC
27:36का उपयोग करके आकार का सटीक अनुमान नहीं
27:37लगाया जा सकता है।
27:38तो, अब हम प्रयास के लिए क्या टेक्निक्स(Techniques)
27:39देखते हैं, आइए, हम पहले से ही इस मूल्य
27:40निर्धारण टेक्निक्स ( pricing technique ) को देख चुके
27:41हैं, फिर हम अन्य टेक्निक्स (Techniques) के बारे में
27:42देखेंगे, हम पहले एक्सपर्ट जजमेंट
27:43बेस टेक्निक्स (expert Judgement based techniques.) देखेंगे।
27:44यहां, हम देखेंगे कि ये ऐसी टेक्निक्स(Techniques)
27:45हैं जो एक्सपर्ट जजमेंट बेस टेक्निक्स
27:46(expert Judgement based techniques) के तहत आ रही हैं, जो
27:47कि बेसिक एक्सपर्ट जजमेंट (basic expert judgement)
27:49है, जो कि औसत अनुमान लगाने वाले सर्वसम्मति
27:55का आकलन करते हैं और डिलीवरी (delivery) से
28:01पहले हमें बेसिक एक्सपर्ट जजमेंट
28:05(basic expert judgement)के बारे में बताते हैं।
28:07इसलिए, यहां यदि आप अनुमान के लिए बेसिक
28:10एक्सपर्ट जजमेंट टेक्निक्स (basic expert
28:12judgement technique)का उपयोग कर रहे हैं, तो यहां
28:14क्या हुआ है, एक या एक से अधिक एक्सपर्ट(Expert)
28:15, सॉफ्टवेयर कॉस्ट (Software Cost)का अनुमान लगाते
28:16हैं, यह प्रक्रिया तब तक चलती रहती है
28:17जब तक कि एक्सपर्ट(expert) के बीच कुछ सहमति
28:18नहीं बन जाती। इस पद्धति का उपयोग
28:19करने का लाभ यह है कि यह बहुत ही सरल
28:20अनुमान है, यह एक बहुत ही सरल अनुमान पद्धति
28:21है, यह सटीक हो सकता है, अगर एक्सपर्ट
28:22(Expert) को सिमिलर सिस्टम्स (similar systems. ). का प्रत्यक्ष
28:23अनुभव है।
28:24लेकिन अगर एक्सपर्ट (Expert)के पास उस सिस्टम(system)
28:25का अनुभव नहीं है जिसे आप डेवेलोप
28:26(develop)कर रहे हैं तो अनुमान गलत हो सकता
28:27है। यह अनुमान बहुत गलत हो सकता है, अगर
28:28इस तरह का कोई सिस्टम (System)उपलब्ध नहीं है
28:29जो आप डेवेलोप (develop)कर रहे हैं, तो आप एक
28:30एवियोनिक्स सिस्टम डेवेलोप (avionics system develop)कर
28:31रहे हैं और ऐसा कोई एक्सपर्ट (expert)नहीं
28:32है जिसके पास एविओनिक्स (avionics ) का ज्ञान हो
28:33, फिर; जाहिर है, अनुमान गलत होंगे।
28:34तो, अब हम बेसिक एक्सपर्ट जजमेंट मेथड(Basic expert
28:35judgement method ) के इस स्टेप्स(Steps) के बारे में देखते
28:36हैं। तो, इस मेथड (Method)में मैं पहले ही आपको
28:37बता चुका हूँ कि एक्सपर्ट(Expert) का एक ग्रुप(group) होगा,
28:38एक व्यक्ति जो कोऑर्डिनेटर(Coordinator) के रूप में कार्य
28:39करेगा। कोऑर्डिनेटर (Coordinator)प्रत्येक एक्सपर्ट
28:41(Expert)को एक स्पेसिफिकेशन और एक एस्टिमेशन
28:44फॉर्म (specification and estimation form ) प्रस्तुत करता
28:46है। आप किन गतिविधियों को कोआर्डिनेट(Coordinate
28:47) करेंगे, आप कोऑर्डिनेट(Coordinate ) के सामने प्रत्येक
28:48एक्सपर्ट(expert) के स्पेसिफिकेशन और एस्टिमेशन (specification
28:49and estimation ) को प्रस्तुत करेंगे और कोऑर्डिनेटर
28:50मीटिंग(coordinator meeting) के एक ग्रुप(group) को बुलाता
28:51है जिसमें एक्सपर्ट कोऑर्डिनेटर (expert
28:52coordinator )और एक दूसरे के साथ एस्टिमेशन
28:53(Estimation)के टॉपिक (Topic) पर चर्चा करते हैं।
28:54इसलिए, कोऑर्डिनेटर(coordinator) उस मीटिंग (Meeting)को
28:55बुला सकते हैं जहां एक्सपर्ट (Experts )उन
28:56कोऑर्डिनेटर (Coordinators) और अन्य एक्सपर्ट्स
28:57(experts)के साथ एस्टिमेशन (Estimation)के टॉपिक (Topic
28:58)पर चर्चा करेंगे, फिर एक्सपर्ट(experts)
28:59गुमनाम रूप से फॉर्म (form)भरेंगे। तब कोऑर्डिनेटर
29:00एस्टिमेशन (coordinator estimation) का सारांश तैयार
29:01करता है और वितरित करता है, कोऑर्डिनेटर
29:02(Coordinator)एक सारांश तैयार करता है और फिर वह
29:03पुनरावृत्ति के रूप में एस्टिमेशन(Estimation)
29:04का सारांश वितरित करता है। फिर कोऑर्डिनेटर(coordinator
29:05) एक ग्रुप मीटिंग (group meeting )को विशेष रूप
29:06से बुलाता है, जिसमें एक्सपर्ट (experts ) द्वारा
29:07पॉइंट्स (points)पर चर्चा करने पर ध्यान केंद्रित
29:08किया जाता है, जहां उनके एस्टिमेशन(Estimation)
29:09व्यापक रूप से भिन्न होते हैं।
29:10इसलिए, यदि यहां मान लिया जाए, तो पांच
29:11एक्सपर्ट्स(five experts) और उनके एस्टिमेशन(estimation
29:12) व्यापक रूप से भिन्न हैं, तो फिर से कोऑर्डिनेटर(coordinator
29:13) एक बैठक बुलाएगा और चर्चा करेगा कि
29:14भिन्नता क्यों है, क्योंकि प्रोजेक्ट
29:15(project)के समान पैरामीटर (parameter) हैं, इसलिए एस्टिमेशन(estimation)
29:16में भिन्नता है ? उन्होंने चर्चा की । फिर एक्सपट्स(experts)
29:17, उन नामों को फिर से गुमनाम रूप से
29:18भरेंगे और स्टेप्स 4 और 6 को कई राउंड के
29:19लिए पुनरावृत्त किया जाएगा, जब तक कि वे
29:20एक सर्वसम्मति के जजमेंट तक नहीं पहुंच
29:21जाते, यह प्रोसेस रीपीट (process repeat )होगी।
29:22अब, हम जानते हैं कि एक एक्सपर्ट (Expert)क्या
29:23है, वास्तव में एक एक्सपर्ट(expert) एक स्पेशल
29:24सिस्टम (special system) से फेमिलिअर (familiar)है
29:25और उसके पास एप्लीकेशन अरे (Application area) के बारे
29:26में इनफार्मेशन (information)है जो आप डेवेलोप(develop)कर
29:27रहे हैं और आप जिन टेक्निक्स (Techniques)का
29:28उपयोग कर रहे हैं। विशेष रूप से यह बहुत
29:29उपयुक्त है जहां मौजूदा कोड(code) को
29:30मॉडिफाइड (Modified)किया जाना है और मौजूदा
29:31कोड(code) अगर पहले से ही है और आप ुइसे मॉडिफाइड
29:32(Modified)करने का प्रयास कर रहे हैं, तो आप
29:33यह एस्टिमेशन(Estimation)लगा रहे हैं। इस मामले
29:34में बेसिक एक्सपर्ट जजमेंट तकनीक (basic
29:35expert judgement तकनीक) बहुत उपयोगी होगी, लेकिन
29:36शोध से पता चलता है कि
29:37एक्सपर्ट जजमेंट (expert judgement) प्रैक्टिस(Practice)
29:38में किसी दूसरी मेथडोलॉजी (Methadology) पर बेस्ड (based)
29:39है जिसे (अनलॉजी मेथडोलॉजी ( Analogy Methadology) कहते है।
29:40तो, आइए देखें कि हम इस अनलॉजी मेथडोलॉजी
29:41(Analogy Methadology) को देखेंगे। तो, आइए देखते हैं
29:42कि बेसिक एक्सपर्ट जजमेंट मेथड(बेसिक
29:43एक्सपर्ट जजमेंट मेथड )किन स्टेप्स(steps)से
29:44गुजर सकती है, जैसा कि मैंने पहले ही
29:45आपको बता दिया है, यह एक अनलॉजी मेथडोलॉजी
29:46(Analogy Methadology) बेस्ड (based)है जिसके स्टेप्स (Steps)
29:47इस प्रकार हैं। फिर पहले प्रेजेंट प्रोजेक्ट
29:48(Present Project)की इन महत्वपूर्ण विशेषताओं की पहचान
29:49करें। फिर पहचानें या प्रीवियस प्रोजेक्ट
29:50(Previous Project) की समान विशेषताओं को देखें।
29:51फिर देखें कि क्या अंतर है, यदि अंतर
29:52है तो पता करें कि क्या प्रेजेंट प्रोजेक्ट
29:53(Present Project)और प्रीवियस प्रोजेक्ट (Previous Project)
29:54कोई अंतर है या नहीं। फिर पता करें कि वे
29:55क्या कारण हैं जिनके कारण वे डिफरेंट
29:56(different)हैं जो मिस्टेक (Mistake)या रिस्क (Risk)के
29:57संभावित कारणों का पता लगाते हैं। फिर
29:58इस अनिचिचित्ता को कम करने के लिए उपायों
29:59को मैजर (Measure) करें, फिर आपको इस अनिश्चितता
30:00या रिस्क (risk)को कम करने के लिए कुछ उपाय
30:01अपनाने होंगे।
30:02जैसा कि मैंने आपको पहले ही बताया है
30:03कि बेसिक जजमेंट तकनीक (basic judgment technique)
30:04वो मूल जजमेंट तकनीक (judgment technique) है जो अनलॉगी
30:05(Analogy) द्वारा एस्टिमेशन (Estimation)पर बेस्ड (Based)है।
30:06तो, अनलॉजी (Analogy)द्वारा एस्टिमेशन(Estimation)से
30:07आपका क्या अभिप्राय है? एक प्रोजेक्ट
30:08(project)की कॉस्ट (cost)को एक ही अनुप्रयोग
30:09डोमेन(Domain) में एक समान प्रोजेक्ट (Project)के
30:10लिए प्रोजेक्ट (Project)की तुलना करके कैलकुलेट
30:11(Calculate)किया जाता है। तो, मान लीजिए, आपने
30:12एक प्राइवेट आर्गेनाइजेशन अकादमिक इंस्टीटूशन(
30:13private organization academic institution) के लिए एक प्रोजेक्ट
30:14(Project)डेवेलोप (develop)किया है और इसके बाद आप
30:15एक प्रोजेक्ट मैनेजर (Project Manager)के रूप में
30:16आप इसे डेवेलोप(develop)कर रहे हैं, एक गोवेर्मेंट
30:17इंस्टीटूशन (government institution) के लिए क्या
30:18अकादमिक सिस्टम(academic system) है, ये एक जैसे
30:19टाइप की एप्लीकेशन (Application) है।
30:20यहाँ आप उन प्रोजेक्ट्स (Projects) की तुलना कर सकते
30:21हैं जो आपने अकादमिक ऑटोनोमस सिस्टम (academic
30:22autonomous system)को डेवेलोप (develop)करने में खर्च
30:23की हैं, प्राइवेट आर्गेनाइजेशन या
30:24प्राइवेट यूनिवर्सिटी(private organization or private university) के
30:25लिए जो प्रोपोसड (Proposed)है; इसका मतलब
30:26है, गवर्नमेंट उनिवेर्सित्य (government university, )के लिए,
30:27फिर आप देख सकते हैं कि एस्टिमेशन (Estimation)क्या
30:28हो सकता है। मन लीजिये थोड़ा भिन्न हो सकता
30:29है, लेकिन यह उचित रिजल्ट (result)दे सकता
30:30है। तो, यहाँ एक प्रोजेक्ट
30:31(Project कॉस्ट (cost) के लिए प्रोजेक्ट (project)की
30:32तुलना समान अनुप्रयोग डोमेन (domain)में एक समान
30:33प्रोजेक्ट (Project)से की जाती है। इसलिए,
30:34एक उदाहरण मैंने आपको पहले ही दे दिया
30:35है कि यदि आपने पहले से ही एक प्राइवेट
30:36इंस्टीटूशन (private institution ) के लिए एक प्रोजेक्ट
30:37(Project)डेवेलोप (develop)की है और फिर एक गवर्नमेंट
30:38अकादमिक इंस्टीटूशन . (government academic institution.) के
30:39लिए एक समान प्रोजेक्ट (Project)डेवेलोप (develop)कर
30:40रहे हैं। तो, आप प्रोजेक्ट्स (projects)की तुलना कर सकते
30:41हैं और तदनुसार अनुमान लगा सकते हैं, नए प्रोजेक्ट
30:42(Project)के लिए जो आप एक गवर्नमेंट यूनिवर्सिटी
30:43या इंस्टीटूशन (government university or institution. ) को ऑटोमेट
30:44(Automate) करने के लिए कर रहे हैं।
30:45अब, एस्टिमेशन अनलॉगी (estimation analogy)के फायदे
30:46यह है कि यह सटीक हो सकती है, यदि एक प्रोजेक्ट(project)
30:47का डाटा (data)डेट। और पीपल एंड टूल्स (people
30:48and tools ) एक ही हैं, तो यह सटीक हो सकता है,
30:49यदि प्रोजेक्ट डाटा (Project data) जो पहले से
30:50आपके लिए उपलब्ध हैं औरपीपल एंड टूल्स
30:51(people and tools ) भी एक ही हैं तो यह फायदे की बात
30:52होगी, नुकसान यह है कि यह बहुत असंभव
30:53है, अगर कोई कम्पेटिबल प्रोजेक्ट (compatible project
30:54) टैकल (tackle) नहीं की गई है तो ।
30:55यदि इस प्रकार का समान प्रोजेक्ट (project)पहले
30:56से नहीं किया गया हैं, तो तब , आप प्रेजेंट
30:57प्रोजेक्ट (Present project) के लिए एस्टिमेशन
30:58(Estimation)नहीं लगा सकते हैं। तो, यह नुकसान
30:59होगा। इसलिए, इसे व्यवस्थित रूप से
31:00कॉस्ट डेटाबेस (Cost database) की आवश्यकता
31:01है। इसलिए, जो भी प्रीवियस प्रोजेक्ट (Previous Project)हैं,
31:02आपको कुछ डेटाबेस (database)में उनकी विभिन्न
31:03कॉस्ट (cost)को बनाए रखना होगा। तो, यह
31:04व्यवस्थित रूप से आवश्यक है, उनके कॉस्ट
31:05डेटाबेस (Cost database) को बनाए रखें, ताकि आप
31:06भविष्य में उपयोग कर सकें।
31:07तो, अब फिर से हम बेसिक एक्सपर्ट जजमेंट
31:08टेक्निक ( basic expert judgement technique) पर वापस जाते
31:09हैं कि क्या हैं, क्या नुकसान हैं, इसे निर्धारित
31:10करना बहुत कठिन है। इसी तरह, विभिन्न
31:11फैक्टर्स (factors)का डॉक्यूमेंटेशन (documentation)करना कठिन है,
31:12जो एक्सपर्ट्स (Expert)या एक्सपर्ट्स (experts)के
31:13ग्रुप (groups)द्वारा उपयोग किए जाते हैं।
31:14एक्सपर्ट्स (Experts)पक्षपाती हो सकते हैं, क्योंकि
31:15आखिरकार वे मनुष्य हैं, एक्सपर्ट्स
31:16(Experts)पक्षपाती हो सकते हैं, वे आशावादी या
31:17निराशावादी हो सकते हैं।
31:18भले ही वे ग्रुप कंसेंसस ( group consensus)से कम हो गए
31:19हों और एक्सपर्ट जजमेंट मेथड ( expert judgement
31:20method) हमेशा अन्य कॉस्ट एस्टिमेशन मेथड ( cost
31:21estimating methods)जैसे एल्गोरिथम माठोड (ALgorithm method)का अनुपालन
31:22करती है। इसलिए, हमेशा एक्सपर्ट जजमेंट
31:23मेथड ( expert judgement method), यह अन्य ेस्टिमशन (estimation)पद्धति
31:24जैसे एल्गोरिथम माठोड (ALgorithm method)का अनुपालन
31:25करता है।
31:26तो, अब हम दूसरा रिसीव (रिसीव ) करेंगे जो
31:27वेटेड एवरेज एस्टिमेट्स (weighted average estimates) है। यहां,
31:28वेटेड एवरेज एस्टिमेट्स (weighted average estimates) को एक
31:29सेंसिटिव एनालिसिस एस्टिमेशन(sensitive analysis
31:30estimation) के रूप में भी जाना जाता है और यहां
31:31तीन एस्टिमेशन (estimation)केवल एक के बजाय प्राप्त
31:32किए जाते हैं, क्योंकि यदि आप एक पर जा रहे
31:33हैं; तो यह हो सकता है कि यह पूरी तरह
31:34से सही न हो। तो, एक के बजाय तीन एस्टिमेशन
31:35(Estimation)प्राप्त किए जाते हैं।
31:36तो, एक सबसे अच्छा केस (case)है या ऑप्टिमिस्टिक
31:37केस( optimistic case) है वो O है, जो सबसे खराब
31:38केस (case)है, निराशावादी केस (case) या सबसे अधिक
31:39संभावना वाला केस (case) है वो Pहै ,जो माध्य,
31:40सबसे ज्यादा केस है वो हम M लेते हैं
31:41और अब, यह तुलना में अधिक एक्यूरेट एस्टीमेट
31:42(accurate estimate) प्रदान करता है जब हम केवल एक एस्टीमेट
31:43(Estimate)पर विचार कर रहे हैं। तो, फिर इनका
31:44उपयोग एस्टीमेट (Estimate)बनाने के लिए एक फार्मूला
31:45(Formula)में किया जाता है। तो, वह फार्मूला
31:46(Formula)है,
31:47एस्टिमेटेड एफर्ट (Estimated effort ) = (O + 4M + P) / 6
31:48तो सबसे पहले हम इसकी वैल्यू(value) निकालेंगे
31:49की सबसे बेस्ट केस(best case) , वर्स्ट कसे(worst
31:50Case) एंड मध्यम केस(Medium case) कौन सा है उसके
31:51बाद हम एस्टिमेशन एफ्फोर्ट्स(estimation
31:52efforts) निकालेंग।
31:53. यह वही है जिसमें नाम का एवरेज एस्टिमेशन
31:54(average estimation) लगाया गया है। दूसरी मेथड (method
31:55) है कंसेंसस एस्टिमेशन (consensus estimation)यहां, कंसेंसस
31:56एस्टिमेशन सेशन (consensus estimating session )आयोजित करने
31:57के स्टेप्स (steps) इस तरह से हैं कि पहले
31:58आपको एक ब्रीफिंग (brefing )करनी है, जो प्रोजेक्ट
31:59(project ) पर एस्टिमेशन (estimation ) लगाने वाली
32:00टीम(Team) को प्रदान की जाती है, फिर प्रत्येक
32:01व्यक्ति को एस्टिमेशन (estimation ) लगाने के लिए
32:02वर्क कॉम्पोनेन्ट(work Component) की एक लिस्ट (list
32:03) प्रदान की जाती है। इसलिए, प्रत्येक
32:04व्यक्ति वर्क कॉम्पोनेन्ट(work Component) की एक लिस्ट (list
32:05) प्रदान करेगा, उन्हें एस्टिमेशन (estimation ) लगाना
32:06होगा। फिर प्रत्येक व्यक्ति स्वतंत्र
32:07रूप से प्रत्येक वर्क कॉम्पोनेन्ट(work
32:08Component) के लिए ऑप्टिमिस्टिक वैल्यू , मॉसटी लिकेल्य
32:09वैल्यू और पसिमिस्टिक वैल्यू का एस्टिमेशन
32:10(optimistic value, most likely value or pessimistic value ka estimation )लगाता है।
32:11फिर एस्टिमेशन (estimation ) को व्हाइटबोर्ड
32:12(whiteboard )पर लिखा जाता है और फिर प्रत्येक
32:13व्यक्ति उसके बेस (base ) और आसुमप्टीओं
32:14(assumption ) पर चर्चा करता है जिनके बेस (base ) पर
32:15उन्होंने एस्टिमेशन (estimation ) तैयार किए हैं
32:16और अंत में, कुछ सुझाव आ सकते हैं फिर एस्टिमेशन
32:17(estimation ) का एक रिवाइज्ड सेट (रिवाइज्ड set) तैयार
32:18किया जाता है। फिर हमें क्या लेना है,
32:19हम आपसे एस्टिमेशन (estimation) का एक रिवाइज्ड
32:20सेट (रिवाइज्ड set) प्राप्त कर रहे हैं जो आपके
32:21पास average है जो आपको O , M और P वैल्यू (value ) का
32:22एवरेज (Average) देता है। आपको ऑप्टिमिस्टिक
32:23वैल्यू (optimistic value) के लिए एवरेज (average ) लेना
32:24होगा और फिर पेसिमिस्टिक वैल्यू (Pessimistic value ) के
32:25लिए और फिर मोस्ट लिकेल्य वैल्यू (most
32:26likely value) क लिए है, इनकी गणना की जाती है और
32:27अंत में, इन वैल्यू (value) का उपयोग उपरोक्त
32:28फार्मूला (formula ) में किया जाता है जिसे
32:29हमने देखा है। तो, इस तरह से आम सहमति
32:30का पालन किया जाता है।
32:31और अगला डेल्फी एस्टिमेशन (डेल्फी Estimation) है; इसलिए,
32:32यह आम सहमति एस्टिमेशन तकनीक(estimation technique) का
32:33एक रूप है। यहाँ, जैसा कि मैंने आपको पहले
32:34ही बताया है कि यह कंसेंसस एस्टिमेशन(consensus
32:35estimation) का एक रूप है, यहाँ experts (Experts)की एक
32:36टीम(team) भी होगी और एक्सपर्ट्स(Experts)के
32:37बीच कोऑर्डिनेट (Coordinate)के लिए उनका कोऑर्डिनेटर(Coordinator)वहाँ
32:38होगा।
32:39एक्सपर्ट्स एस्टिमेशन(Expert Estimation) को स्वतंत्र
32:40रूप से ठीक कर सकते हैं। जेनेरल एक्सपर्ट्स
32:41(General Experts) वे एस्टिमेशन (Estimation)को स्वतंत्र
32:42रूप से करेंगे। वे अपने ेसशमशन (Estimation)के
32:43पीछे की औचित्य का उल्लेख करेंगे कि
32:44औचित्य क्या है, उन्होंने क्या धारणा ली है।
32:45वे उस पत्र में भी उल्लेख करेंगे, तो
32:46कोऑर्डिनेटर (Coordinator)किसी भी असाधारण या औचित्य
32:47को नोट करता है यदि किसी एक्सपर्ट्स
32:48(Experts)ने लिया है, तो वह कोऑर्डिनेटर (coordinator)को
32:49किरकुलते (circulate)करता है या अन्य एक्सपर्ट्स
32:50(Experts)के बीच एस्टिमेशन (Estimation)को किरकुलते
32:51(Circulate)करता है।
32:52दूसरे एक्सपर्ट्स (Experts)से क्या एस्टिमेशन
32:53(Estimation)प्राप्त करने के बाद प्रत्येक
32:54एक्सपर्ट्स (Experts)अपने कॉस्ट (Cost)का फिर से
32:55एस्टिमेशन (Estimation)लगाते हैं, लेकिन यहाँ एक्सपर्ट्स
32:56जुडजेमेंट (Expert judgement) में एक दूसरे से कभी
32:57नहीं मिलते हैं या हाँ, एक्सपर्ट्स
32:58जुडजेमेंट (Expert judgement) में उन एक्सपर्ट्स
32:59(Experts) को प्रशिक्षित करते हैं जो वे एक
33:00दूसरे से मिलते हैं, लेकिन यहाँ डेल्फी
33:01एस्टिमेशन (Delphi Estimation)में cordinator (Coordinator)सबसे महत्वपूर्ण
33:02भूमिका निभाता है। वह अन्य एक्सपर्ट्स
33:03(Experts)के बीच दूसरों के बीच घूमेंगे, एक्सपर्ट्स
33:04(Experts)अपने दृष्टिकोण पर चर्चा करने के
33:05लिए एक दूसरे से कभी नहीं मिलते हैं।
33:06तो, डेल्फी का मतलब है डेल्फी दो या अधिक
33:07राउंड में एक एक्सपर्ट का सर्वे है। इसलिए,
33:08दूसरे दौर से शुरू होने वाला पहला दौर
33:09खत्म हो गया है, पहले दौर के दूसरे दौर
33:10से शुरू होने के बाद एक प्रतिक्रिया पिछले
33:11दौरों के रिजल्ट के बारे में दी गई
33:12है, फिर वही एक्सपर्ट्स जो उन्हीं मामलों
33:13का एस्टिमेशन करता है जो एक बार की राय
33:14से अधिक प्रभावित होते हैं अन्य experts।
33:15वह अन्य एक्सपर्ट्स के सुझावों या राय
33:16को ध्यान में रखता है और फिर वह एक ही
33:17मामलों का एक बार फिर से एस्टिमेशन
33:18करता है, वह फिर से उसी पैरामीटर का
33:19पुनर्मूल्यांकन करता है। तो, यहाँ
33:20महत्वपूर्ण गुमनामी है।
33:21प्रस्तुत करता है, फिर कोऑर्डिनेटर
33:22(coordinator)एक ग्रुप मीटिंग (group meeting)बुलाता है जिसमें
33:23वो एक्सपर्ट (expert)से कोऑर्डिनेट (coordinate)
33:24और एक-दूसरे के साथ एस्टिमॅटिन (Estimation)के
33:25टॉपिक (topic)पर चर्चा करते हैं और फिर एक्सपर्ट(Expert)से
33:26वे फॉर्म(form)भरवाते हैं। गुमनाम रूप
33:27से। और कोऑर्डिनेटर (coordinator)एक िटेरटीओं
33:28फॉर्म (iteration form)पर एस्टिमेशन (estimation)का सारांश तैयार
33:29करता है और डिस्ट्रीब्यूट (distribute)करता है और कोऑर्डिनेटर
33:30(coordinator)एकग्रुप मीटिंग (group meeting) में एक्सप्लेन
33:31(explain) करता है, जहां एस्टिमेशन (estimation) व्यापक
33:32रूप से डिफरेंट (different)होता है। और एक्सपर्ट(Expert)
33:33फिर से गुमनाम रूप से, फॉर्म भरते हैं,
33:34और स्टेप्स (Steps)4 और ६ बहुत राउंड (round)के
33:35लिए इट्रेटे (iterate))होते हैं।
33:36इसलिए, अंत में, हमने प्राइस (Price) पर चर्चा
33:37की है। हमने पहले एस्टिमेशन (estimation)लगाने
33:38के तरीके को जीतने के लिए इस प्राइस(Price)की
33:39एक method (Method)पर चर्चा की है, फिर हमने प्रेजेंट
33:40(Present)किया है कि LOC या SLOCका उपयोग करके साइज
33:41(SIZE) का एस्टिमेशन(Estimation)कैसे लगाया जाए। साथ ही
33:42एक्सपर्ट जजमेंट बेस एस्टिमेशन टेक्निक्स
33:43(expert Judgement based estimation techniques) पर चर्चा की। तो, वेटेड
33:44एस्टिमेशन (वेइट्स एस्टिमेशन ) ने एवरेज
33:45एस्टिमेशन (Average Estimation), कंसेंसस एस्टिमेशन
33:46(consensus estimation ) और डेल्फी (Delphi)को एक्सप्लेन
33:47(Explain)किया। हमने अनलॉय बेस्ड एस्टिमेशन
33:48(analogy based estimation)की भी व्याख्या की है। तो, ये रेफ़्रेन्स
33:49(references) हैं, जो हमने लिया है।
33:50धन्यवाद्

About this transcript

This page contains the full transcript of Lecture 17: Project Estimation Techniques (Contd.) by NPTEL IIT Kharagpur, generated from the public captions YouTube serves with the video. The transcript has 5,425 words across 729 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.