आवश्यकताओं को कितना समय लगता है?

आवश्यकताओं को कितना समय लगता है?

विषय - सूची

क्या आपने कभी सोचा है कि आपकी आगामी परियोजना के लिए आवश्यकताओं को बनाने में कितना समय लगेगा? व्यापार विश्लेषक और प्रबंधक अक्सर यह सवाल पूछते हैं।

सॉफ़्टवेयर और उत्पाद विकास से संबंधित अधिकांश मुद्दों के लिए, कोई एक आकार-फिट-सभी उत्तर नहीं है; प्रतिक्रिया वास्तव में आपकी अनूठी परिस्थितियों पर निर्भर करती है।

कई चर इस समस्या में योगदान करते हैं, प्रमुख उद्योग औसत सुझाव देते हैं कि एक परियोजना के प्रयास का कितना प्रतिशत आवश्यकताओं के विकास के लिए समर्पित होना चाहिए जैसे कि इकट्ठा करना और प्राप्त करना।

आवश्यकताओं को एकत्रित करने जैसी गतिविधियों के लिए आवश्यक समय और प्रयास की उचित मात्रा का निर्धारण आप कैसे कर सकते हैं? इसमें कोई आश्चर्य की बात नहीं है कि अलग-अलग बेंचमार्क के डेटा हमेशा एक दूसरे के साथ खिलवाड़ नहीं करते हैं। यह भी बहस का विषय है कि क्या ये "सामान्य" परियोजनाएँ आपके अपने समान हैं। इस समस्या को हल करने में आपकी सहायता करने के लिए, मैंने इस आलेख में अपनी पुस्तक "सॉफ़्टवेयर आवश्यकताओं के बारे में अधिक" से कुछ विचारों को अनुकूलित किया है - इसे देखें!

उद्योग बेंचमार्क

बेंचमार्क की संभावित उपयोगिता का एक उदाहरण प्रदान करने के लिए, कृपया तालिका 1 देखें। प्रस्तुत डेटा विभिन्न आवश्यकताओं के लिए उद्योग के औसत को इंगित करता है और उन परियोजनाओं के संबंध में प्रोटोटाइप प्रयास करता है जो आकार में 10,000 फ़ंक्शन पॉइंट (कोड की लगभग एक मिलियन लाइनें) से प्राप्त होते हैं। केपर्स जोन्स का "सॉफ्टवेयर आकलन, बेंचमार्क और सर्वोत्तम अभ्यास।" ये आंकड़े आपकी अपनी परियोजना के लिए कितने प्रासंगिक हैं?

इस तरह के उद्योग बेंचमार्क का उपयोग करना इसकी कमियों के बिना नहीं है। डेटा हमें यह बताने में विफल रहता है कि क्या परियोजनाएँ वास्तव में सफल थीं या यदि सफलता और आवश्यकताओं को पूरा करने के लिए किए गए प्रयासों के बीच कोई संबंध था। यह जानकारी केवल हमें प्रदर्शन का औसत देती है, इस प्रकार प्रत्येक व्यक्तिगत परियोजना की सफलता का सटीक वर्णन करना मुश्किल हो जाता है।

एएलएम आवश्यकताएँ प्रबंधन उपकरण

आवश्यकताओं को इकट्ठा करने जैसे कार्यों के लिए टीम के प्रयासों का 10% या उससे कम आवंटित करना फायदेमंद साबित हो सकता है, बशर्ते कि वे विश्लेषण पक्षाघात में फंस न जाएं। लोकप्रिय धारणा के विपरीत अपनी आवश्यकता विकास प्रक्रिया को बढ़ाने में अधिक मात्रा में प्रयास करने से वास्तव में उत्पादन में तेजी आएगी। इस अवधारणा का लाभ उठाने से किसी भी परियोजना के लिए निवेश पर भारी रिटर्न मिलता है!

जैसा कि मैंने कोडक में नियोजित होने पर छोटी परियोजनाओं पर काम किया था, हमारी टीम ने आवश्यक गतिविधियों के लिए कुल प्रयास का 15% से 18% आवंटित किया। हमने पाया कि इस निवेश ने डिलीवरी के बाद आवश्यक परिवर्तनों की मात्रा को कम कर दिया। कारणों और प्रभावों को निश्चितता से जोड़ना मुश्किल है, लेकिन यह संभावना है कि हमारी कम रखरखाव दर काफी हद तक महत्वपूर्ण उपयोगकर्ता भागीदारी की खेती के कारण थी।

यह पता लगाने की कोशिश करना कि आपकी अगली परियोजना के लिए कितनी समय की आवश्यकता होगी, एक मुश्किल सवाल है, और सटीक रूप से गेज करना मुश्किल हो सकता है। फिर भी सौभाग्य से, चित्र 1 हमें उन चरों के बारे में कुछ जानकारी देता है जो उक्त प्रक्रिया को छोटा या लंबा कर सकते हैं; उन आवश्यक आवश्यकताओं को बनाते समय अधिक प्रभावी ढंग से अनुमान लगाने में आपकी सहायता करना।

आपका अपना अनुभव

आरंभ करने के लिए, यह निर्धारित करने के लिए कि किस प्रकार का प्रयास विशेष रूप से आवश्यकताओं को एकत्रित करने के लिए समर्पित था, पिछली परियोजनाओं के डेटा की समीक्षा करना उपयोगी हो सकता है। यह आपको यह आकलन करने की अनुमति देगा कि अतीत में आपकी विकास प्रक्रिया कितनी सफल रही है और भविष्य के प्रयासों के लिए इसकी लागत का अनुमान लगाते समय इस जानकारी का उपयोग करें। एक अतिरिक्त कारक के रूप में, अपने शुरुआती अनुमानों को चित्र 1 का संदर्भ देकर समायोजित करें जो आगामी परियोजनाओं और बेंचमार्क के बीच अंतर को रेखांकित करता है और साथ ही आपकी परियोजना से संबंधित किसी अन्य प्रासंगिक विचार को ध्यान में रखता है। 1 (कोई प्रभाव नहीं) से लेकर 0 (महान प्रभाव) तक के पैमाने पर चित्र 5 में सूचीबद्ध प्रत्येक तत्व का आकलन करके, यह मूल्यांकन आपको उन जोखिम कारकों का पता लगाने में मदद कर सकता है जो आपकी आवश्यकताओं की विकास प्रक्रिया को बढ़ा सकते हैं।

आवश्यकताएँ प्रबंधन प्रणाली

अन्य तत्वों के साथ-साथ, परियोजना के जीवन चक्र पर विचार करना आवश्यक है। यह न मानें कि सभी आवश्यकताओं को शुरुआत में एक अनुक्रमिक या जलप्रपात दृष्टिकोण की तरह जमा किया जाना चाहिए (चित्र 2 में बिंदीदार रेखा द्वारा सचित्र)। एक विशिष्ट "आवश्यकताओं का चरण" होने के बजाय, विकास के प्रत्येक चरण के माध्यम से आवश्यक आवश्यकताओं की एक सरणी के बारे में सोचें। जैसे-जैसे हमारी सिस्टम रिक्वायरमेंट्स स्पेसिफिकेशन (SRS) विकसित होती है और परिवर्तन अनुरोध उत्पन्न होने लगते हैं, हमें आवश्यकता बेसलाइन को सक्रिय रूप से प्रबंधित करने में मेहनती रहना चाहिए। यह एक सतत प्रक्रिया है जिस पर लगातार ध्यान देने की आवश्यकता है।

पुनरावृत्त और वृद्धिशील दृष्टिकोण

चुस्त विकास के दृष्टिकोण, जैसे स्क्रम, एक प्रगतिशील मार्ग अपनाते हैं। यह उपयोगकर्ताओं को उत्पाद की संभावित उपयोगी विशेषताओं पर जल्दी से अपना हाथ रखने और आवश्यकतानुसार अपनी आवश्यकताओं को आसानी से संशोधित करने की अनुमति देता है। इस प्रकार डेवलपर्स हमेशा-बदलती व्यावसायिक मांगों को सहजता से रख सकते हैं। फुर्तीली परियोजनाओं के साथ, छोटे लेकिन नियमित आवश्यकता संग्रह प्रयासों (चित्र 2 में ठोस रेखा) के कारण शायद ही कभी बड़ी माँग की पहल की आवश्यकता होती है।

आवश्यकताएँ आधार रेखा

परियोजना की शुरुआत पर ध्यान केंद्रित करने के बजाय, एक फुर्तीली परियोजना में आवश्यकताओं का प्रयास विभिन्न चरणों में फैला हुआ है। आरंभिक अन्वेषणों से इसकी प्राथमिकता स्तर के आधार पर एक बैकलॉग डिटेलिंग कार्यक्षमता प्राप्त होती है। जब विकास और परीक्षण का समय आता है, तो टीमें आवश्यकताओं को परिष्कृत करती हैं ताकि प्रत्येक पुनरावृत्ति के साथ आत्मविश्वास से आगे बढ़ने के लिए उनके पास पर्याप्त विवरण हो।

वर्षों पहले, मैं एक सॉफ्टवेयर डेवलपमेंट टीम का हिस्सा था जिसने सफलता सुनिश्चित करने के लिए वृद्धिशील दृष्टिकोण का लाभ उठाया। प्रत्येक चक्र, हमारी परियोजना तीन सप्ताह के चरणों में जारी की जाएगी, जिसमें पहला भाग आवश्यकताओं की योजना बनाने और उस विशिष्ट वेतन वृद्धि के लिए विकसित करने के लिए समर्पित होगा। हमें इस पद्धति से बहुत अच्छे परिणाम मिले क्योंकि यह कॉर्पोरेट उपयोगकर्ता आधार के लिए हर कुछ हफ्तों में उपयोगी कार्यक्षमता लाता है। टीम ने उपयोगकर्ताओं को बार-बार अपडेट प्रदान करते हुए नई कार्यक्षमता को वृद्धि के साथ तेजी से वितरित करने के लिए लगन से काम किया। ये उपयोगकर्ता अंतर्दृष्टि परियोजना का मार्गदर्शन करने और यह सुनिश्चित करने में मदद करने के लिए अमूल्य थे कि इसके पूरा होने से अधिकतम मूल्य प्राप्त किया गया था।

सभी पहलें छोटे हिस्से में देने के लिए उपयुक्त नहीं हैं। किसी मौजूदा एप्लिकेशन का पुनर्निर्माण करते समय, नई प्रणाली में पर्याप्त स्तर की कार्यक्षमता होनी चाहिए, इससे पहले कि उपयोगकर्ता इसे बदल सकें। भले ही आपकी टीम प्रत्येक प्रोजेक्ट चक्र पर कितना पूरा करती है, उन्हें किसी भी तैयार किए गए रीडो को रोकने और डिज़ाइन, कोड या परीक्षणों के पुनर्लेखन को रोकने के लिए उस विशेष अनुक्रम की आवश्यकताओं को समझना होगा।

योजना आवश्यकताएँ उन्मूलन

जब आप किसी नई परियोजना के लिए आवश्यकताओं को संकलित करना शुरू करते हैं तो यह अक्सर अधिक जटिल होता है। आपके विश्लेषकों को जिन गतिविधियों को करने की आवश्यकता है, उन पर विचार-मंथन करते समय, ध्यान रखें कि क्या उन्हें इन जैसे कर्तव्यों को पूरा करना होगा:

  • बातचीत के माध्यम से उत्पाद चैंपियन के साथ संबंध बनाना।
  • इंटरएक्टिव कार्यशालाओं और गहन साक्षात्कार के माध्यम से अंतर्दृष्टि एकत्रित करना।
  • संभावित सुधारों का पता लगाने के लिए मौजूदा रिकॉर्ड और उत्पादों की जांच करना।
  • सर्वेक्षणों का निर्माण, प्रसार और गूढ़ रहस्य।
  • डिजाइन, और प्रोटोटाइप का आकलन, मॉडल का अध्ययन, और सफलता के लिए अन्य आवश्यकता दृष्टिकोण।
  • जोखिम मूल्यांकन के माध्यम से सफलता प्राप्त करना, सुरक्षा और सुरक्षा प्रोटोकॉल सुनिश्चित करना, संभावित विफलताओं का विश्लेषण करना और जोखिम परीक्षा आयोजित करना।
  • डेटा रिपॉजिटरी में अपनी आवश्यकताओं के विवरण को लॉग करना।
  • आवश्यकताओं के विनिर्देशों में विस्तृत मांगों की सावधानीपूर्वक जांच करना।
  • सूचीबद्ध आवश्यकताओं से टेस्ट केस तैयार करना, और सावधानीपूर्वक उनके प्रदर्शन का मूल्यांकन करना।
  • पूरी तरह से समीक्षा या परीक्षण के बाद, सटीकता सुनिश्चित करने के लिए विशिष्टताओं को फाइन-ट्यून करें।

भविष्य की परियोजनाओं के लिए आवश्यक प्रयासों का बेहतर अनुमान लगाने में सक्षम होने के लिए, आपकी टीम को आवश्यकताओं को पूरा करने, विश्लेषण, विनिर्देशन और सत्यापन के भाग के रूप में किए जाने वाले विभिन्न कार्यों के बारे में सीखना आवश्यक है। यह ज्ञान आगे आपको यह समझने में मदद करेगा कि प्रत्येक कार्य में कितना समय लगता है और आपकी परियोजना के प्रदर्शन को बेहतर बनाने में सहायता करता है। इसका जरूरी मतलब यह नहीं है कि सभी गतिविधियों को हर उद्यम पर करने की जरूरत है, बल्कि यह समझने की जरूरत है कि क्या करने की जरूरत है, यह एक सफल परिणाम की ओर ले जाता है।

इस पोस्ट को शेयर करना न भूलें!

मॉडल-आधारित सिस्टम इंजीनियरिंग दृष्टिकोण और आवश्यकता प्रबंधन प्रक्रिया के बीच तालमेल

दिसम्बर 17th, 2024

11 पूर्वाह्न ईएसटी | शाम 5 बजे सीईएसटी | सुबह 8 बजे पीएसटी

फर्नांडो वलेरा

फर्नांडो वलेरा

सीटीओ, विज़र सॉल्यूशंस

आवश्यकताओं से लेकर डिजाइन तक के अंतर को पाटना

एमबीएसई और आवश्यकता प्रबंधन प्रक्रिया के बीच की खाई को पाटना सीखें।