कि अजय को कि असलामुलाइकुम ए साफ्टर प्रोजेक्ट मैनेजमेंट कोर्स के सिर्फ में में आज हम एक नया टापिक शुरू कर रहे हैं कि इस टॉपिक के हम्यत आपके लिए बहुत ही ज्यादा है क्योंकि जब आप चीज प्लान करते हैं प्लानिंग में कास्ट और resource utilization और estimation के एक बड़ा role होता है कोई भी project अगर आपने take up करना है तो आपको पता होना चाहिए कि इस project या activity को complete करने के लिए how much money is involved, how much time is involved एंड व्हाट काइंड अप डिस्ट्रोसेस रिक्वायर्ड तो इस चीज को समझने के लिए और एज प्रोजेक्ट मैनेजर इस पर करना आपके लिए जो ना बहुत जरूरी है कि प्रोजेक्ट के रिसोर्सेस की कास्ट एस्टिमेशन जो है वो कैसे हो सकती है there could be few scenarios in this case हो सकता है कि आपके पास already एक plan जो है वो सामने हो और आपको कहा गया हो कि आप इस प्लान के मताबग प्राजेक्ट को एडिस्क्यूट करें दैट एस सिंपल एस प्राजेक्ट मैनेजर आपको क्या करना होगा दाव फस्ट स्टेप यहाँ टो डू एस चेक देट के इस जिज़ प्लैन इस एक्टिविटी को प्रोजेक्ट को कंप्लीट करने के लिए बनाया गया है इसके एस्टिमेट्स क्या थे वट वर द बेसेज आफ एस्टिमेट्स to calculate the efforts going to be put टू कंप्लीट द असाइनमेंट और देखोड़ बेनर स्नेरियो यू माइट है बिन आस पाइड अथारिटीज टो डेवलप अकास्ट एस्टिमेट फॉर ए प्रोपोज्ड और अप्रूव प्रेक्टिकली ये भी होता है कि आर्गनाइजेशन ने अगर आप एक प्रोजेक्ट विन कर लिया हो विनिंग ए प्रोजेक्ट थ्रू बिडिंग और कंपेटिटिव प्रोसेस और यू बिन दिमा प्लेस टिक आग्नाजेशन आपको काम जो ना सेंट किया गया हो आग्नाजेशन जो कास्ट एस्टिमेट किसी भी कंट्रैक्ट को या अपने के लिए दिए गए हों यू एज प्रोजेक्ट मैनेजर विल हैफ टो क्रिएट यूर ओन डिसोर्सेस एंड यू एप टो क्रिएट यूर ओन एस्टीमेट फॉर तो आगनेशन expect from you कि आपको अगर ये assignment दी जाए ये project अगर आपको complete करना है तो you come up with your own estimates तो फिर आपको naturally depending upon the project requirement estimation जो है वो करनी पड़ेगी or you might be asked to comment on already prepared estimates तब आप क्या करेंगे इन स्टेरियो को जैन में रखते हुए, आज के टॉपिक में हम ये डिस्क्रेशन करेंगे कि वाट आर दे इंपार्टेंट फैक्टर्स, कंसेप्स, रिगार्डिंग एस्टिमिशन्स, पर्टिकुलरली विद रेफरेंस्ट टू, साफ्टरेड वेल् वह बहुत सारी चीजें बहुत सारी इंफॉर्मेशन दी गई हैं लेकिन रेलिवेंट्स टू देट लोकेशन वेट्स वेरी इंपोर्टेंट आपको अगर एक point of reference मालूम नहीं होगा, then how you can say how much time it will take to reach to next destination. ये तो हमने किसी traveling point of view से जोने का example quote की. अब हम बात करते हैं project implementation की. अगर आपको इस चीज़ का बेहतर तरीके से अंदाजा नहीं है, how much resources and time is required to complete that activity, तो आपके लिए उस project को timely complete करना in a cost effective way बड़ा मुश्कल होगा. And remember, वो हमने शुरू में जिकर किया था, किसी भी project को complete करने के लिए, you have to trade off between the cost, time and the performance.
अब आप द रिसोर्सेस विच आफ गएंग टू वीजिट टो कंप्लीट द असाइनमेंट कुछ कंसेप्ट से एस्टीमेशन के बारे में पहले हम इसके पर बात कर लेते हैं, then we'll talk about other features. To start with, software cost and effort estimation will never be an exact science, यह आप समझ लें. Estimates are just estimate. बट दिशोट बी नेर टू देख चुएल अभी आपके एक्सपीरियंस की बात होगी आपके स्किल की बात होगी अवेलेबिलिटी एंड जाओ दिफरेंट टूल्स प्रेस्टीमेट द रिसोर्सेस कास्ट एंड डूरेशन यह पर डिपेंट करेगा कि आप जो रियलिस्टिक व्यक्ति आप जहन में रखें कि यह एक एक्जेक्ट एस्टिमेट जो है इस नाट एक्जेक्ट साइंस प्रैक्टिकली अगर आपसे डेविएट भी करते हैं टूट दे एंड आफ द प्राजेक्ट एक्टिविटी इस नाट नेगेटिव साइंस बड़ यू शुट नट बीवे आफ फ्रॉम व्हाट यू एवेस्टिमेटेड एंड व्हाट एक्शनी हैपन्स यह इसका एक प्रेट है जो आपको समझना यह चार फैक्टर्स ऐसे हैं जो आपके estimation को उनकी values को effect कर सकते हैं so you have to concentrate these and concentrate on these while you are estimating the cost and other parameters however the software project estimation can be transformed from a black art to a series of systematic steps that provides estimate with acceptable risk ब्लैक आर्ट मींट्स विदाउट गिविंग एनी लॉजिकल रिजनिंग्स विदाउट रिवीलिंग डिफरेंट लॉजिकल स्टेप्स यू आर कमेंग अप वेद दर अप एस्टिमेट एर अफ आइडिया बे द रीजन एंड बेसिस फाइड एस्टिमेट्स वह लेबरेट हो उसके लिए कुछ स्टेप्स हैं विच नीचे पर परफॉर्म द विडिस्कस व्हाट कोट बी possible situations जब आप किसी भी activity के लिए cost estimation or the time estimation की बात करें पहला तो बड़ा simple है delay estimation until late in the project and you can achieve hundred percent actual एक्स्टीमेट एफ यू डिले बाइट आइम एक्टिविटी एस कंप्लीट अनेर टू कंप्लीट सेकंड बेस एस्टीमेट आउंट प्रोजेक्ट देट आवार लेडी बिन कंप्लीटेड एफ यू है एक्सेस टू देट इनफॉर्मेशन एफ यू आप लकी एंड यू फिल्ड इस आप उनके estimation को जब आप use करें third could be यूज डेलेटिवली सिंपल डिकंपोजिशन टेक्निक प्रोजेक्ट कास्ट एंड एफ़ाइड एस्टीमेट नॉट डिपेंडिंग अपने प्रोजेक्ट कंप्लेक्सिटी और आप विज़न के बारे में अपने प्रोजेक्ट को विशेष करने के लिए आप उस प्रोजेक्ट को मैक्रो लेवल पर उसके कुछ डिकंपोजिशन कर लेते हैं। यहाँ पर decomposition से मुराद यह है कि you break down different activities or the phases.
If you recall हमने शुरू में बात की थी, software development projects में. विवर्क थ्रू द फेजेस एक्टिविटीज को लॉजिकली रिलेट करके तो यू माइट है टेन फेजेस यू माइट है वे टू फेजेस आफ यू डिपेंड अपने प्रोजेक्ट कंप्लेक्स टी आप इसको ब्रेकडाउन करके एस्टिमेट करते हैं एस पर द फेस विव डिवाइडेड लास्ट यूज वन और मोर इंप्रिकल मेथड फर साफ़डर कास्ट एंफर एस्टिमेट्स लेट सीज चार डिफरेंट पॉसिबल आप शन यह स्नेरियों जाएं इनको practically how we can look into that पहले step तो यह था कि आप delay कर दे estimation उपर till the activity is complete someone else is working on it, you have been asked to prepare the estimates unfortunate this is useless अगर project activity complete होगी and still you are preparing the estimates तो आपकी technical skill, आपकी input बेकार होगी so it's not practical to delay the preparation of the cost estimate तो first option is out एस्टिमेट शोड़ बी प्रिपेयर टाइमली सो देट एड एन एक्सीक्वेशन आफ द प्रोजेक्ट बड़ा वर विशुरू रिकगनाइज द लांगर वी वेट द मोर वी नो एंड द मोर वी नो और प्रोजेक्ट तुम कंप्लेक्स एवी इन्वेस्टमेंट एं� इस बैटर टू स्पेंड सम टाइम बिफोर एकम कंक्लूडिंग देस्टीमेट्स बट दैट पीड़ियर शोड नाट बिलांग एड शोड बी द ब्लॉट टाइम पीड़ियर रिक्वायर तो देट द टाइमली एस्टिम और यू कम अब विद पार्शल एस्टिमेट देश डेंजर एस्टाइम आपने एस्टिमेट तो कर दिया इसमें इतने आई फ्रेड के साथ आपने एस्टिमेशन की कंक्लूयन किया कि बिकम वेरी डिफिकल्ट फॉर द मैनेजमेंट टो रियली इस तरह के estimates, software development projects के completion के लिए, execution के लिए suitable नहीं होते, नाहीं, जो हमने पहले भी discuss किया था, कि you come up with a wild guess, and you try to complete the information in the shortest possible time frame, then you are taking a lot of risk, चीज़ें शुरू में clear नहीं होती हैं, the more you know about the project, the more you know about the references, relevances, बेटर यू बी एन ए पोजिशन टू एस्टीमेट प्रॉपरली लेकिन इसका वेट पीड़ियर देट डिपेंड्स अपन द प्रॉजेक्ट रिक्वायरमेंट टाइम देट अब आलरेडी बिन कंप्लीटेड विद इन दार्मेशन आर यू एक्सेस टू द इनफॉर्मेशन दाइट काइन आफ प्रोजेक्ट एक्विटी वास कंप्लीटेड एक्सटर्नली दिस ऑप्शन कैन वर्क रिजनेबली वेल यदि अपने प्रोजेक्ट पर अधिक तरह के लिए पास अधिक तरह और अधिक तरह के लिए प्रोजेक्ट पर अधिक तरह है, तो आप एक बढ़ावा प्रश्न होते हैं, जिसके लिए अधिक तरह के लिए अ दिन चार देशाइज डिवेशन उन चीजों के एक दिफर्स और दिन वार्मेंट इन विद पर टिवर प्राड़ेक्ट और सर्वेस फैसिलेक्ट विवेट टू विपलीमेंटेड इज आल टू गैदर डिफरेंट अब प्रोजेक्ट तो सिमिलर था दिन वार्मेंट वेरिट इट गएंट विप जो सिमिलर प्रोजेक्ट में एक्टिविटी में एड थे टाइम नहीं होगे स्वेट इस क्वाइट डेंजरेस एफ यू सिंपली पास आन द प्रोपोर्शनेट रेशोस एंड प्रोजेक्ट में थे विदाउट कंसल्टिंग और कंसिटिंग द नियुक्त व्यापण बियंग डन सुझाव टू बिकेट फॉल वेन यू आर आपको अगर review करने के लिए कहा गया हो और फिर आप प्रोपरेट के लिए आपको प्रेश एस्टिमेट्स प्रश्न रखें और आपको बहुत बह� डिकंपोजेशन की जब हम बात करते हैं तो अब हम बात कर रहे हैं dividing the bigger complex project into smaller units then these smaller units are converted into different phases and activities simple approach हो सकती है, detailed approach भी हो सकती है अगर आपने इसकी simple approach में इसके phases को, decomposition को limit किया है major parts में और इस सिर्फ में दूसरा हम यह कह सकते हैं कि यूज वन और मोर इंपिरिकल मेथड फॉर साफ्टर कास्ट एंड एस्टिमेशन एक पर आप रिलाय न करें ट्राइड एन अथर टैक्टिक एंड टूल एंड देन कंपेयर दिस टू उससे आपको जोने बेहतर estimate करने में मदद मिलेगी ये दोनों option जिसमें micro level की decomposition हो not the detailed one or using some commonly used empirical methods इन दोनों को combine ले अगर हम use करें तो उससे we can come up with a viable approaches to software project estimations आईडियली स्पीकिंग द टेक्निक्स नोटेड फर इच ऑप्शन शोड बी अप्लाइड इन टेंडम इच यूज़ डेज एक रास्ट चेक टू द अदर्स टेंडम मींस अब आपके पास एफ यू कैन इमेजिन प्रेक्ट दूसरी अप्रोच आप यूज कर रहे हैं, वह एक अनुसार वाल्यू सेट है, आप वाल्यू सेट कर रहे हैं, आप यू है बिना आस्ट डेवलप फैसिलिटी प्राड़ेक्ट और सर्वेस टू साल व साइटर पॉब्लम आफ द यूजर प्लाइंट स्टेक होल्डर आर्गनाजेशन आर टू वेरी आपके assignment दिए गई हो और यह कहा गया हो कि estimate करें कि how much time money and effort is required in one single piece mill you cannot do that you have to decompose this project एंड पर्टिकुलरली वेन वी टाक अबाउड द साफ्टर डिवेलमेंट प्रॉजेक्ट साफ्टर प्रॉजेक्ट हेयर कास्ट एफर्ट एस्टीमेशन रिलेटर टू द यूमन बिंग एंड टेक्नोलोजीज वेरी� कि आपने के ओवराल गोल यह अचीफ करना है अब जगत अचीफ करना है तो देट इज एम एक्टर फिजिकली प्रोडूसिंग द थिंग डिक्वाइड specification to be outlined उनको आप further break down कर दे ताकि आपके पास जो intermediate results हैं intermediate results के लिए अब आपका जो decomposition process है that requires again the estimations इन तमाप को आप cumulatively sum up करेंगे you will come up with the overall estimated figure प्रोब्लम आपको क्रिएट फैसिलिटी फॉर दिस रिजन विक डिकंपोस प्रॉब्लम रिक्रैक्टर राइजिंग एट एज ए सेट आफ smaller and hopefully more manageable problems problem is a kind of Target output we are talking about by decomposing a project into major functions and related software engineering activities cost and effort estimates can be performed in a stepwise fashion. वो steps क्या हैं वो हम डिस्कस करते हैं एस्टिमेशन एट्स वेरी डिफिकल्ट टो डू बट एट आफन नीड इट विदाउट एस्टिमेशन एट्स एग्रेट रिस्ट वर्क आने एनी प्रॉजेक्ट इट एस क्रिएटेड यूज्ड अगर आप एक जोड़ान करने के लिए आश्चा है तो आपको एक जोड़ान करने के लिए आश्चा है तो आपको एक जोड़ान करने के लिए आश्चा है तो आपको एक जोड़ान करने के लिए आश्चा है तो आपको एक जोड़ान करने के लिए आ� एक्नॉमिकली और नॉट सो रिसोर्स एस्टीमेशन एडिवेस देयर और फॉर्स प्रोजेक्ट प्लैनिंग इज आईटरेटिवली डन दन जू रिक्वार द रिसोर्स एस्टीमेशन तो एज ए प्रोजेक्ट मैनेजर आपको एस्टिमेशन टेक्निक में एक्सेल करना मैंडेटरी है। है चाहे आप साफ्टवेर प्राजेक्ट को एग्जिक्यूट कर रहे हैं डेवलप कर रहे हैं और यू आर प्रिपेरिंग ए फिजिबिलिटी स्टेडी और यू आप बिन आप्स टू कमेंट आबा कमेंट आन द प्राजेक्ट अब आप एनी एक्टिविटी आफ प्राड़क विच एवं प्रेड बाई सम अधर ग्रुप आप पीपल एंड यू अब इन आफ टू कमेंट आन इज एफेक्टिव फाइनेंचली वायबल, इस एट आप्टिमली, इट हैस बिन डन आप्टिमली और नाट, तो उन तमाम को जब आपने रिस्पॉंड करना है, तो यू विल बी यूजिंग दे बेसिस आप कास्टिंग, तो कास्ट एस्टिमिशन कि एज ए प्रोजेक्ट मैनेजर यू हैव टो वी वेरी केरफुल सेंसिटिव एंड यू हैव टो एव एक लोग जायां देश टीमेशन प्रोसेस इन एस्टिमेशन को हम डिफरेंट एस्पेक्ट्स में उनके कंस्टेप्ट्स को जोना मजीद डिटेल से जोना डिस्कस करते हैं अपने प्रदेश ने अपने प्रदेश के लिए प् तो आपको इसको break down करना है लेवल आफ एफर्ट डन बाइड आफ मीडल मैनेज मीडल मैनेजर जैन द टेक्निकल स्पोर्ट परसेंट वर्स इस द स्मालर अमाउंट आफ एफ़र्ट एंड टाइम इज एस्टीमेटेड आर कैल्कुलेटेड बाइड आप लीडर सुपर्वाजर एंड एक्सपर्ट्स एस्टीमेट द स्केजूअल जब आप टोटल टाइम फ्रेम कप्ट एक्टिविटी स्टार्ट होगी कब कंप्लीट होगी कब फेस्ट टाट होगा कब फेस्ट कंप्लीट होगा वेंट एंटायर प्रॉजेक्ट जो एंटर वी स्टार्ट एंड कंप्लीटेड एंड वें दिफरेंट रिसोर्सेस आफ रिक्वायर तो यह एस्टिमेट जो कर दो जाएगा दिल्ली सम प्रोजेक्ट जिसमें यह तमाम चीजें रिक्वायर ना हो बट एनी वन आफ दिजेज बेंडेटर ली आप आर्ट आफ देश टीमेशन टेक्नीक अब आपको एक पूरा निर्भावाण ने आपको एक पूरा निर्� वर्टिकली अब यू लुक एड वाइ एक्सेस विवेब एंडर परसेंट परसेंटेज में हमने साइज एस्टिमेट्स ग्रोथ वह दिया है इन लाइन्स आफ सोर्स प्रोजेक्ट में वे राइटिंग प्रोग्राम एफर्ट डिजाइन के बाद प्रोग्रामिंग टेक्निक से कंस्ट्रेक्शन एक तो उसका वन आफ द पैरामीटर जो कामन ली यूज होता है देट इज लाइन्स आफ सोर्स कोड तो इन टर्म्स आफ लाइन्स आफ सोर्स कोड जो है नामने फैरमेटर पर जो लिया है वाई एक्सेस पर एक्स पर वो different stages हैं completion की, if you concentrate on the screen आप ये देखेंगे shaded area जो है initial stage पे जिसको हम कहते है initial product definition, जो भी product consideration में है उसके बारे में आप discussion start हो रही है कितने months चाहिए अब हम आपके प्रश्न पर आप एज ए मैनेजर आपने तो उसको calculate करना है कि these are the main months or main hours which are required to generate or produce those intermediate or final products फिर जब आप आते हैं यह approved product definition पे और वो features defined हो गए हैं पहले product के बारे में features में grey areas होंगे recall our discussions हमने पहले requirement analysis की बात की हुई थी requirement analysis के नतीजे में फिर उसको technical transformation for the developers वो stages को आप जैन में रखें तो शुरू में जो specification होती है, जो wishes होती है, जो desires होती है, users की, stakeholders की उसको finally in line with the agreement made or the scope of the project defined अब आप एक बहतर position में हैं ये judge करने के लिए कि what is the exact definition और specification of that particular product अब level of effort को आप बेहतर तरीके से यहाँ पे define कर सकते हैं but still uncertainty is much higher at this stage reason वही कि there could be some of the modules or some of the tools or utilities जिनके बारे में आप जकीन से नहीं कह सकते stage पे whether these are compatible or usable or available or not फिर जब requirement analysis पे आ जाते हैं अब आपको exactly पता है के what kind of tools are needed for this project और इस वक्त आप एक बेहतर position में होते हैं यह decide करने के लिए कि you might have opted so many other options उन तमाम को eliminate करके जो best fit है requirement analysis के बाद stage के बाद आप सिर्फ उनको pick करते हैं तो all those guesswork items जो है न वो eliminate हो जाते हैं यहाँ पे अब आपके uncertainty level जो ना reduce हो गया है जब आप architecture पे आते हैं now you become more sure about designing the product or the facility तो नेची व्हाट एवर एट इस रिक्वायर्ड इस ग्रेंट वीडियो फिर आप डिटेल डिजाइन पर आ गए तो डिटेल डिजाइन आपने specification work out कर ली, SRS बन गई, आप सिर्फ source code, in terms of their modular approach, जो भी project के requirement हो, उसके मताबग आप करने जा रहे हैं, you are in a best position to judge the man are required to work on, to produce that particular product or the facility.
और आपके प्राजेक्ट कमप्लीट हो जाती है, आप अच्छा हैं, क्योंकि आप आपको बट दिज मस्ट बी नेयर टू देख ट्वेल नेयर टू एक्ट्रोल में आपको दो एडवांटेजेज होंगे फर्स्ट यू वेल कंप्लीट था प्राइम विद रिड्यूस कास्ट एंड सेकंडली यू विल बिन ए पोजीशन टो कैच अप विद टाइम फ्रेम आईस के रिवर्स किया है इफ यू बेड एस्टिमेट्स यू विल रन ला कास्ट ओवर रन एंड यू विट रबल विद ताइम ओवर रन एंड वर्ड विल नॉट बी ए गुड प्रोजेक्ट मैनेजमेंट तो estimation के reference से ही आब हम एक और practical step की तरफ आते हैं, estimation a critical factor, in a software project, unless you are sure that your estimates are accurate, you cannot make much progress, तो यह आप हमेशा जैन में रखें, you have to have a very good practical estimates, कि वह ज़मेशन फर एस्टिमेशन अब द फैक्टर्स कास द मोस्ट क्रिटिकल एफर्ट द फैक्टर इस डिफिकल्ट टो कैलकुलेट एट रिक्वायर्स experience job skill knowledge and of course it also requires some homework before estimating प्रभाव का लगभग और प्रभाव का वजन का व इंट्रोड्यूसिंग द रिस्क इन दिस रिगार्ड तो रिस्क इनवार्ड एन एग्जिक्यूटिंग कंप्लीटिंग द एसाइनमेंट इस वेरी सीरियस द रिस्क फैक्टर वेरीज फ्रॉम अ सिंपल काशिय प्रश्न पर बड़कर निर्भाव यू शोड नॉट डूप्लिकेट द रिसोर्सेस एविजविज यू शोड नॉट मिस एनी क्रिटिकल रिसोर्स विच रिक्वायर टो कंप्लीट द प्रॉजेक्ट तो दिजाएगी आदमा की फैक्टर्स विच आ� तो टाइम एंड रिसोर्सेस तो वह अपने चेक कर लिए नॉट यू है वे ने प्रोजेक्ट प्रो� अब आपके लिए ज्यादा आसान है उसकी कास्ट को और डिवेशन को और दुसरी एफर्ट्स को टेक्निक को जोने इंप्लाई करना। इस पर जो प्लान फॉर द रिसोर्सेस एंड स्केजूल द प्रॉजेक्ट देखाओं एस्टिमेशन पर तमाम चीजें जो न घूम रही हैं बेटर एस्टिमेट गिव जू आ बेटर आइडिया बाउट द प्रोजेक्ट साइज इफ यू आर क्लियर अब आप द साइज आफ द प्रोजेक्ट देन यू आर आल्सो श एस्टिमेशन आफ रिसोर्सेस कास्ट एंड स्केजूल फार एस साफ्टर एंजिनियरिंग एफर्ट जनरली रिक्वेयर एक्सपीरियंस द मोस्ट रिटिकल एक्सेस टू द गुड इस्टॉरिक वहाँ पर भी आपके लिए estimation point of view से guidelines होंगी, sometimes resources and estimates are done in a non-professional way, तो वो अगर आप उसके reasoning पे उसको देखेंगे, अगर उसको देखेंगे, even a failed story, failed project, unsuccessful project, incomplete project, उनको भी, अगर वो similar nature of the project हैं, तो I must emphasize on that, that you must go through that. वह आपको indirectly help करेंगे not to repeat the similar kind of mistakes which caused the failures towards those projects or the activities. So the access to the historical data, when I say good historical information, that must have relevance and that must be some time frame reference also. अब आपको एक ऐसा project जो decades old time में मिला हो, it's of useless. अगर वो similar kind of project भी है यह टाइम फ्रेम जो 10 साल का है उसमें बहुत सारी चीज़ें चेंज हो गई हैं, 5 साल का या 15 साल का, तो not only the relevance is important for good information, it's a time frame also, and of course जो तीसरा important aspect है, वो है इसके stakeholder, users, environment जिसमें प्राड़िक्ट या facility को जो use करना है, and the third important aspect in this regard is courage to commit to quantitative prediction, when qualitative information is all that exist, एस्टिमेशन में qualitative data will not help much, it's a quantity we are talking about.
क्योंकि जब हमने time की बात करनी है, जब हमने cost की बात करनी है, these are the quantitative. Yes, when we talk about the level of effort, वहाँ पे qualitative aspect ज़रूर आ जाता है, but that qualitative aspect must be converted into quantitative form. क्योंकि एफर्ट को ultimately उस level of effort की जो quality है, उसको आपको convert तो करना है, how much time is required, how many people are required, what kind of people are required is a qualitative aspect, but how many people are required for how long is a quantitative aspect, तो वो आपको define करना पड़ेगा So, to summarize this point, qualitative assessment should be avoided, although it should be considered, but qualitative assessment should be avoided, rather quantitative estimate should be promoted अब हम आते हैं इस critical factor के reference से एक और एहम point पे and that is estimation carries inherent risk and this risk leads to uncertainty यह तो आप जैन में रखने हैं if your estimates go wrong doesn't matter you have done your best effort after going through doing the all necessary homework, speed work अब अगर यह नहीं है, तो यह नहीं बड़ा तरह है। जैसे मैं पहले बार बता रहा हूं, इस प्रदर्शन नहीं एक बड़ा तरह भी हो जाना चाहिए। प्रस्टेप्ट तो उससे आपके कंपिटेंट्स और जो आपके स्पेड बर्क है उसके कुछ ड्रॉब बैक्स जैनेवर शो हो रहे होते हैं और देर कोड बी ए पॉसिबिलिटी देट यू वर्किंग आने यूनिक प्रॉजेक्ट यू फेल्ड टो एडे एंड बेस्ट अपना आल अवेलेबल इनफॉर्मेशन विद आईएवर्ट यू हैव मेड यू वर आनेबल टू रिलेट टू सिमिलर काइन आफ एक्टिविटी देर यू एक्सपीरियंस यू जॉब knowledge will give you a lead have a best estimation with reference to logical rationales and come up with estimates उस सुरत में अगर estimate deviate भी करेंगे because of the innovative nature because of the new technique technology being implied उसमें इतना प्रॉब्लम नहीं होगा अगर आपकी actual और estimated effort में बहुत ज़्यादा कोई gap आ भी गया है but still for this kind of thing for the new kind of technological projects आपको speed work और extra effort जो है न वो additional करनी पड़ेगी अब इनमें जो गैफ्स आ जाते हैं, actual plan versus plan में, उनके critical factors क्या हैं, वो और aspect अब हम देख लेते हैं.
First is the project complexity. Of course, जब project की nature जो है ज्यादा complex होगी, project is bigger in size, complex in nature, तो उसके estimation करना मुश्किल हो जाएगा. It has a strong effect on the uncertainty inherited in planning because of the complexity. एक विशेष ने विशेष उसमें जो estimations होंगी, efforts की, cost की, वो उसमें जो factor है, इसका uncertainty का बज़ ज्यादा होगा. For that point of view, those group of people feel this project is very complex and estimation is very difficult.
Compared to that, look for a software team. अब उन्होंने इस तरह का project e-commerce का पहले भी कर चुके हैं वो और ये अब उनकी 10th, 20th, 5th assignment है फर देम द सेम प्रॉजेक्ट नॉट कंप्लेक्स क्यों बिकास देवा लेडी बर्क आंटिस का इन आफ प्रॉजेक्ट सो Complexity is relative term. जो team किसी भी project को complete करने के लिए adapt की जाती है, उनका experience और उनका skill जो है, that makes the project complex most of the time. तो complexity की बुनियात पे estimates को way off कर देना is not logical. So it needs to be checked and remembered.
A number of qualitative software's complexity measures can be applied. एज पर नीड आफ द प्रोजेक्ट वहां बाद में इसको रेफर भी करेंगे कि इस कंपलेक्सिटी मैयर्स को हॉट विकेंट सार्ट आउट डब्लीवीएस में वर्क ब्रेकडाउन स्ट्रक्चर में ज्यादा डिटे पर्शिक्ष पार्ट में नॉट अब हम बात कर रहें उसकी रिफाइनमेंट ऑफ डिजाइन और उसके बाद उसकी कोडिंग है तो यह रहें और हमने यह पहले भी डिस्कस किया है कई दफ़ा कि साफ्टर प्रोजेक्ट में ह्यूमन फैक्टर एज एनदर सब्स्टेंशल कंटिब्यूशन इंटू देट अब प्रॉब्लम यहां पर यह है कि हम एस्टिमेट कर रहे हैं चुके कोडिंग और डिजाइनिंग में HR फैक्टर, human factor सब्स्टेंशल है initial stage पे जब estimation के हम बात कर रहे हैं और project complex भी है चोके design अभी exist नहीं करता code के बारे में उसके detailed designing भी नहीं हुई जो नियुक्त जॉब टास्ट ट्रेस्टीमेट फॉर मैन मंस्ट रिक्वायर तो एज कंट्रेयरी टू द फर्स्ट जिसमें प्रोजेक्ट की कंप्लेक्सिटी जो है वो relative term है this is the real situation and that's a genuine one इसके उपर आपको as a project manager you have to do some speed work and the homework to have a best estimate in the absence of having a complete design in the beginning प्राजेक्ट कंप्लेक्सिटी के रेफरेंसी तीसरा प्रेंट यह है कि रिगारलेस आफ दा प्राजेक्ट कंप्लेक्सिटी और दा कोड्स एपसेंट्स आफ डिजाइन्स वायर फार एस्टिमिशन अदर मोर्स और सब्जेक्टिव यूज इन दिस प्रॉड़ेक्ट तो उनके एस्टीमेशन फैक्टर जो है अर्ली स्टेजेस में वह डिफाइन करना मुश्किल है और आपको तो अधिक विटाग वर्ड फंक्शन प्रेंट्स दिजाद द क्रिटिकल प्रिटिकल एलिमेंट्स एंड साफ्टरेड वेल्मेंट्स विच आई यूज़्ड वायल यू आप प्रोडूसिंग एनी साफ़ड प्राड़ेक्ट सर्वेस और फैसिलिटी सो जिए कंप्लेक्सिटीज में अब सब्सक्राइब करना और ना कोड डिजाइन का इनिशियल सेज पर एक्जिस्ट ना करना और प्राजिक कंप्लेक्सिट सेल अ ये वो चीज़े हैं जो आपके estimations बट यू मस्क अंसिडर दिस वेरियस ऑप्शंस विच रिलेट फूल अप्राजेक कंप्लेक्सिटी और स्केब उसके रखते हुए आप estimation techniques को जोने use करेंगे second is the project size is another important factor that can affect the accuracy and efficacy of estimates sometimes it happens that the product service or facility is prepared or developed for अगर प्रोजेक्ट का साइज जन्म बढ़ा दिया गया और नैचरी यह होता है कि जून प्रोडक्ट या प्रोजेक्ट का साइज बढ़ता है, यूजर ग्रूप, डिफरेंट काइन अव यूजर ग्रू अब the similar kind of facility जो एक focused target group के लिए त्यार की गई थी, उस facility को एक versatile group के लिए त्यार करना, और जहाँ पे environment भी अब different हो गई है, focused में controlled environment थी, अब ये भी chances हैं, by increasing the size of project geographically or technically, or introducing some more modules of application into that, वो उसकी overall project estimation है, cost estimation है, को judge करने में difficulty पेशाती है and you know as size increases the interdependencies among various elements of the software grows rapidly अब इसको catch up करना it's a tedious and difficult task estimation के सिचले में हम decomposition technique भी use करते हैं जो हमने पहले भी जिकर किया था कि अगर bigger project है, complex project है, उसको divide करते हैं, sub projects में, smaller problems में, then we are in a better position to estimate. लेकिन problem यह है कि decomposition जो है, अगर project की complexity है, अगर जी एक important approach तो है to estimate, rather to have a good estimate, it becomes more difficult because decomposed elements may still be alarming due to the complexity and size of the projects. अब यह तो हो नहीं सकता कि उस प्रोजेक्ट को डिकंपोस करते-करते न्यूमरेस समाल आइटम्स या सब फेजेस बना दिया जाएं इवन उसके logical phasing भी अगर complex project की कर दी जाए, still there is a chance that the divided phase is still complex in nature.
वहाँ पर estimations का factor जो है, that is little bit risky. रिपीट करना चाहूँ, रीट करना चाहूँ, that is a kind of thing which generally happens in your practical life. And that is, what can go wrong, will go wrong. And if there are more things that can fail, more things will fail. ये तो एक light's note था, but practically आप ये जहन में रखें, कि you are making an estimation, you are not going to गिव आफ फॉर्म कमेटेड एस्टीमेट्स अब आप द थिंग एंड वेन यू आप डिलिंग विद अकंप्लेक्स्टीज वह सकते कुछ गलती हो और sometimes it happens कि जब आपको कोई clue नजर ना आ रहा हो then you keep on searching desperately different options तो उस रुप में scenario जो है न ज्यादा complex होता चला जाता है never mind जो इस यह स्किल्स यूज एक्सपीरियंस एंड रेलिवेंस अब नॉलेज टेकल द सिच्वेशन कंप्लेक्स स्ट्रेशन शुड नॉट हर्ट यू आर एट प्रोजेक्ट मैनेजर यू आर प्रोफेशनली और उसके complex project के estimation will be artistically good outcome out of यह स्किल एंड एफर्ट्स यह गॉंट पूर्ट इंटू देख अब हम आते हैं एक और टॉपिक पर दिग्री आफ स्ट्रेक्शन एंड अभी तक हम वो चीज़ें डिस्कस कर रहे हैं जो as a project manager आपको bother करेंगे you have to face these but once you are conscious about these things and you learn that these things may happen उसके लिए आपका mitigation or solution ढूडना आसान हो जाएगा what is the degree of structural uncertainty?
it has effect on the estimation risk उसकी वज़ा इसको हम इस तरह explain करते हैं कि in this context structure refers to the degree to which requirements have been solidified, the ease with which functions can be compartmentalized, and the hierarchical nature of the information that must be processed. आपने इसके ये चीज़ें डिफाइन तो कर दियें बट practically when you convert and try to get the estimations that become difficult. You have a requirement that the degree to which that requirement is needed that is the complexity. इसको जो structural uncertainty है किसी भी service facility और options की वो आपको good estimate बनाने में आपके लिए जोने एक hurdle हो सकती है.
अवेलेबिलिटी आफ दे स्टॉरिकल इनफॉर्मेशन इट है जिस टांग इंफ्लूइंट्स आन एस्टीमेशन रिस्ट जितनी ज्यादा ज्यादा यूजफुल इनफॉर्मेशन आपका वेलेबल है विद रेफरेंस टू देट काइंड आफ प्रोजेक्ट एक्टिविटी यू managing आपके लिए estimation करना ज्यादा आसान है by looking back we can emulate things that worked and improved areas where problem arose very simple इस प्रोजेक्ट के बारे में इसकी इस्तिक पता चल गया सिमिलर नेचर प्रोजेक्ट के बारे में जो लेवल आफ एफर्ट हैं उसके वह आपके लंबे आ गई दरीज जो उस प्रोजेक्ट यह एक्टिविटी के रेफरें पाट इस डाटा और इन फॉरमेशन दिफिकल्ट एक और इंपोर्टेंट पैटर मैट्रिक्स का साफटर मैट्रिक्स का एंड जब पास प्रोजेक्ट पर प्रभावित शॉटवेर मेटरिक्स पर पास प्रोजेक्ट पर पास प्रभावित शॉटवेर मेटरिक्स पर पास प्रभावित शॉटवेर मे एंड ओवर आफ रिस्क रिड्यूस्ट सो आल देट इंफॉर्मेशन विच इज मेड अवेलेबल एज रिजल्ट आफ हिस्टोरिकल डेटा स्किल स्पेड वर्क देट मस्ट पूट एन एमेटिक फॉर्म एडिट विल हेट टो बेल्ट एगुड एस्टिमेट रिस्क यह बात करने चुके एस्टिमेशन के मौजब बात कर रहे हैं तो रिस्क फैक्टर तो कंसिडर होना ही है रिस्क एडिवाइड बाइट डिग्री इस टेबलेज फॉर रिसोर्सेस कास्ट एंड स्केजूल अब देखना यह है कि रिस्क का लेवल कितना है टो व्हाट एक्सटेंट यू और project requirements are subject to change uncertainty and risk become dangerously high तो ये आप while you are estimating you have to be बहुत अच्छा है कि प्रोजेक्ट रिक्वायरमेंट विशेष बना गया है और प्रोजेक्ट विशेष बना गया है। कि जब स्कोफ के हम बात करते हैं, हम साइज की बात कर रहे हैं, specification की बात कर रहे हैं, requirements are final, just recall cone of uncertainty. but once you are clear about the project scope, size and the requirements, और यह पता कि यह requirement फर्म है, final है, change नहीं होगी, you are in a better position to estimate. लेकिन अगर यह negative है, these things are flexible, then you are in fact taking a great risk in identifying the scope. Let's summarize our discussion regarding estimation as a critical factor. The software planner should demand completeness of function.
performance and interface definitions यह बहुत जरूरी है अगर यह चीजें complete नहीं होगी तो estimation जो है वो एक problem होगा secondly the planner and more important the customer should recognize the variability in software requirements means instability in cost and schedule तो estimation के time पे आपको customer के साथ stakeholder के साथ भी interface करना है contact करना है बिफोर यू आर कम्प्लीटिंग फाइनलाइजिंग यू आर एस्टिमेट्स मेक शुर के आपके कस्टमर, यूजर या क्लाइन उसको इस चीज़ का पता हो के रिक्वार्मेंट चेंज न की जाएं अगर software requirement change होगी तो ये estimate change हो जाएंगे ना सिर्फ ये के estimate change होगे इसका cost के उपर और time frame के उपर जो ना वो impact होगा The customer must understand that while project estimates are being prepared प्रदाव एक्सेक्वेशन आफ द प्राजेक्ट एक्टिविटीज द रिक्वायरमेंट एं� एक्स्टेंशन इनहेंस्मेंट के नाम पर फॉलोआप के तौर पर चीज़ों को जो यह न बढ़ाया जा सकता है but when we are talking about the estimation these things should be fixed during that time while project estimations are being run तो ये वो discussion है जो आज हमने estimation के reference से दो point के हवाले से की अब हम इसको summarize कर लेते हैं और ये discussion हम continue करेंगे next session के लिए भी आज हमने estimation से related concepts जो ना discuss किये डिफरेंट ऑप्शन इसमें हमने फिर कोण आफ अंतरिक जो है वह रेफर किया था उसके बाद फिर हमने के क्रिटिकल इस विशेष के बारे में हमने बात की कि वेन वियर टाकिंग बॉट एस्टीमेशन के कुछ कास्ट एफर्ट रिस्क रिसोर्सेस से रिलेटेड कुछ फैक्टर्स हैं जो एस्टीमेशन को लाइन करते हैं उसमें आप जो भी estimate करें उसके एक तालुख है how complex that project is project size विजाते खुद एक element है जिसमें cost estimation जो है वो effect होती है फिर हमने यह भी discuss किया the degree of structural uncertainty जो चीज़ें planned की जाती हैं अब उसके uncertainty dependent upon how the things are going to be implemented structurally वो उसको effect करते हैं cost estimate को झाल अब नहीं भी कहा था वेलेबिलिटी आफ हिस्टोरिकल इनफॉर्मेशन यह पॉजिटिव फैक्टर है इफ द इनफॉर्मेशन अवेलेबल एड बिकम्स ए प्रॉब्लम एफ यू डाउट that kind of information और आखर में फिर हमने risk से मतालिक जोना चीज़ें discuss की थी और हमने कहा था कि estimation जो है is not exact science estimation should be a best possible good estimate जो के एक्चुअल और प्लैंड में उनका डिफरेंस चुयाना वो कम से कम होना चाहिए तो estimation के इस discussion को अभी हम wrap up करते हैं हम इसको further discuss करेंगे अगले sessions में वोस्तक तक के लिए अल्लाफिस