विज़र सॉल्यूशंस


सहायता
रजिस्टर करें
लॉग इन करें
निशुल्क आजमाइश शुरु करें

आवश्यकताओं की गुणवत्ता को कैसे मापें

यदि परियोजना को सफल होना है तो आवश्यकताओं में गुणवत्ता होनी चाहिए। मानक और शर्तें निर्धारित करके, टीमें उन लक्ष्यों तक पहुँचने की दिशा में अपनी प्रगति का मूल्यांकन कर सकती हैं। किए जा रहे कार्य के आधार पर उपयोग किए जाने वाले मेट्रिक्स अलग-अलग होंगे; हालाँकि, ट्रैकिंग आवश्यकताओं के लिए कुछ सामान्य संकेतकों में शामिल हैं:

  • परीक्षण कवरेज – प्रत्येक प्रणाली के कितने कार्यों का परीक्षण किया गया है?
  • आकलन सटीकता - क्या विनिर्देशों में उच्च स्तर की शुद्धता है?
  • कार्यक्षमता पूर्णता – क्या कार्यक्षमता के सभी क्षेत्रों को पर्याप्त विवरण में निर्दिष्ट किया गया है?
  • स्वीकृति मानदंड स्पष्टता - क्या दस्तावेज़ीकरण से उपयोगकर्ता स्वीकृति मानदंड आसानी से पहचाने जा सकते हैं?
  • परिवर्तन अनुरोध - विनिर्देशों के लिखे जाने के बाद से कितने परिवर्तन अनुरोध दायर किए गए हैं?

इन गुणात्मक कारकों को नियमित रूप से मापने से, आप यह पहचानने में सक्षम होंगे कि आपकी टीम को अपने प्रयासों पर ध्यान केंद्रित करने और अपनी परियोजनाओं की गुणवत्ता में सुधार करने की आवश्यकता कहाँ है।

आवश्यकताओं की गुणवत्ता को कैसे मापें

विषय - सूची

आवश्यकताओं की गुणवत्ता का आकलन करना क्यों महत्वपूर्ण है?

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

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

उत्पाद का आकार

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

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

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

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

  • एक निश्चित सुविधा का उपयोग करने के लिए कई रास्ते प्रदान करना उपयोगकर्ता अनुभव को बढ़ाता है; हालाँकि, इस तरह के उपक्रम के लिए डेवलपर्स से अधिक समय और ऊर्जा की आवश्यकता होती है, यदि पहुँच का केवल एक तरीका उपलब्ध हो।
  • यहां तक ​​कि अगर आप नई उत्पाद सुविधाओं को लागू नहीं कर रहे हैं, तो मौजूदा ऑपरेटिंग वातावरण को समायोजित करने के लिए बाह्य इंटरफेस जैसे मजबूर डिजाइन और कार्यान्वयन बाधाएं आवश्यक इंटरफ़ेस कार्य की मात्रा में काफी वृद्धि कर सकती हैं।
  • अधिकतम प्रदर्शन सुनिश्चित करने के लिए, त्वरित प्रतिक्रिया की गारंटी के लिए सावधानीपूर्वक एल्गोरिदम और डेटाबेस डिज़ाइन कार्य की आवश्यकता हो सकती है।
  • कठोर उपलब्धता और विश्वसनीयता आवश्यकताओं को पूरा करने के लिए, विफलता और डेटा पुनर्प्राप्ति तंत्र का निर्माण करना आवश्यक है जो समय लेने वाला हो सकता है। इसके अतिरिक्त, आपके द्वारा चुना गया सिस्टम आर्किटेक्चर भी इन मांगों से प्रभावित हो सकता है।

समय के साथ आवश्यकताओं में वृद्धि को ट्रैक करके, उपयोग किए गए आकार मीट्रिक की परवाह किए बिना, आप उपयोगी जानकारी प्राप्त करेंगे। मेरे मुवक्किल ने देखा कि डिलीवरी से पहले उनकी परियोजनाओं में आमतौर पर लगभग पच्चीस प्रतिशत की वृद्धि हुई। इसके अतिरिक्त, उनकी अधिकांश परियोजनाएँ अपेक्षा से कम से कम पच्चीस प्रतिशत अधिक लंबी चलीं! यहाँ कोई संयोग नहीं है — यह स्पष्ट है कि इन दोनों प्रवृत्तियों के बीच एक संबंध है।

आवश्यकताएँ गुणवत्ता

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

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

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

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

चिकित्सा उपकरण जोखिम प्रबंधन

आवश्यकताएँ स्थिति

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

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

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

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

परिवर्तन अनुरोध

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

  • निर्दिष्ट समय सीमा के भीतर परिवर्तन के कितने अनुरोध किए गए हैं?
  • कितने अनुरोधों का उत्तर दिया गया है और कितने अनसुलझे हैं?
  • अनुरोधों के लिए अनुमोदन की दर क्या थी और कितने प्रतिशत को अस्वीकार कर दिया गया था?
  • प्रत्येक अधिकृत संशोधन को निष्पादित करने के लिए टीम ने किस हद तक ऊर्जा खर्च की?
  • अनुरोधों के खुले रहने की सामान्य अवधि क्या है?
  • प्रत्येक सबमिट किए गए परिवर्तन अनुरोध से औसतन कितने आइटम (जैसे, आवश्यकताएं या कलाकृतियाँ) प्रभावित होते हैं?

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

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

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

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

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

समय और प्रयास

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

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

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

समय और प्रयास

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

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

निष्कर्ष

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

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

चोटी

आवश्यकताओं के प्रबंधन और सत्यापन को सुव्यवस्थित करना

जुलाई 11th, 2024

सुबह 10 बजे ईएसटी | शाम 4 बजे सीईटी | सुबह 7 बजे पीएसटी

लुई अर्डुइन

लुई अर्डुइन

वरिष्ठ सलाहकार, विज़्योर सॉल्यूशंस

थॉमस डिर्श

वरिष्ठ सॉफ्टवेयर गुणवत्ता सलाहकार, रेजरकैट डेवलपमेंट GmbH

विज़्योर सॉल्यूशंस और रेज़रकैट डेवलपमेंट के साथ एक एकीकृत दृष्टिकोण TESSY

सर्वोत्तम परिणामों के लिए आवश्यकता प्रबंधन और सत्यापन को सुव्यवस्थित करने का तरीका जानें।