Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
यह अध्ययन एक ऐसा सॉफ़्टवेयर आकार अनुमान मॉडल प्रस्तावित करता है जो रिग्रेशन विश्लेषण का उपयोग करके फंक्शनल साइज मेजर्स (UFP और CFP) को फंक्शनल कॉम्प्लेक्सिटी मेजर्स (CC और YC) के साथ एकीकृत करता है, यह प्रदर्शित करते हुए कि इन मेट्रिक्स को जोड़ना—विशेष रूप से UFP को कॉम्प्लेक्सिटी मेजर्स के साथ—COCOMO II जैसे अनुप्रयोगों के लिए अनुमान त्रुटि को काफी कम करता है और भविष्यवाणी सटीकता में सुधार करता है।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
सॉफ्टवेयर बनाना एक जटिल प्रयास है, जो बिल्कुल एक इमारत बनाने जैसा है, लेकिन ईंटों और गारे के बजाय, इसके निर्माण सामग्री कोड की पंक्तियाँ और कार्यात्मक आवश्यकताएँ (functional requirements) हैं। दशकों से, प्रोजेक्ट मैनेजर यह अनुमान लगाने के लिए कि किसी प्रोजेक्ट में कितना समय और पैसा लगेगा, कोड की इन पंक्तियों को गिनने पर भरोसा करते आए हैं। हालाँकि, यह तरीका त्रुटिपूर्ण है क्योंकि दो प्रोग्राम बिल्कुल एक जैसा काम कर सकते हैं जबकि प्रोग्रामर द्वारा लिखे जाने के तरीके के आधार पर उन्हें लिखने के लिए कोड की मात्रा बहुत अलग हो सकती है। इसे हल करने के लिए, उद्योग ने सॉफ्टवेयर को इस आधार पर मापने का एक तरीका विकसित किया कि वह उपयोगकर्ता के लिए वास्तव में क्या करता है—जैसे इनपुट, आउटपुट और डेटा फाइलों को गिनना—न कि इस आधार पर कि उसे कैसे लिखा गया है। इसे 'फंक्शनल साइज' (functional size) के रूप में जाना जाता है। फिर भी, इस फंक्शनल काउंट में एक कमी है: यह फीचर्स की मात्रा को तो मापता है, लेकिन उन्हें बनाने की कठिनाई को अक्सर अनदेखा कर देता है। एक साधारण फीचर बनाना आसान हो सकता है, जबकि कई ब्रांचिंग पथों (branching paths) और शर्तों वाला एक जटिल फीचर कोडिंग के लिए एक दुःस्वप्न हो सकता है, भले ही दोनों पारंपरिक अर्थों में एक ही "फीचर" के रूप में गिने जाएं।
फीचर के आकार और उसे बनाने की जटिलता के बीच का यह अंतर वह केंद्रीय पहेली है जिसे इंडोनेशिया के शोधकर्ताओं के एक दल ने सुलझाने का प्रयास किया है। उन्होंने यह देखने के लिए काम शुरू किया कि क्या फंक्शनल साइज के माप को स्ट्रक्चरल कॉम्प्लेक्सिटी (structural complexity) के माप के साथ जोड़कर सॉफ्टवेयर प्रोजेक्ट के वास्तविक पैमाने का अधिक सटीक अनुमान लगाया जा सकता है। उनका कार्य सॉफ्टवेयर बनाने के लिए आवश्यक प्रयास (effort) के अनुमान को परिष्कृत करने पर केंद्रित है, जो एक महत्वपूर्ण कार्य है क्योंकि यही निर्धारित करता है कि कोई प्रोजेक्ट बजट के भीतर रहेगा या नियंत्रण से बाहर हो जाएगा। सॉफ्टवेयर के "क्या" और "कितना कठिन है" दोनों को देखकर, उनका लक्ष्य उन लोगों के लिए एक स्पष्ट तस्वीर बनाना था जो इन डिजिटल सिस्टमों की योजना और प्रबंधन करते हैं।
शोधकर्ताओं ने दो वास्तविक दुनिया के सॉफ्टवेयर प्रोजेक्ट्स से डेटा एकत्र करना शुरू किया: एक जो एक कर्मचारी सहकारी समिति (employee cooperative) के लिए डिज़ाइन किया गया था और दूसरा एक रिटेल स्टोर के लिए। उन्होंने सार्वजनिक डेटासेट्स का उपयोग नहीं किया क्योंकि उनमें अक्सर विश्लेषण के लिए आवश्यक विशिष्ट विवरणों की कमी होती है। इसके बजाय, उन्होंने इन एप्लिकेशन्स की टेक्स्टुअल रिक्वायरमेंट्स (textual requirements) को विजुअल फ्लोचार्ट में अनुवादित किया, जिन्हें BPMN डायग्राम कहा जाता है। ये डायग्राम एक सेतु के रूप में कार्य करते थे, जिससे टीम को सिस्टम के प्रत्येक भाग के लिए दो अलग-अलग प्रकार के माप निकालने में मदद मिली। सबसे पहले, उन्होंने फंक्शनल साइज की गणना की, जो उपयोगकर्ता की अंतःक्रियाओं (interactions) और डेटा फाइलों की संख्या को गिनता है। उन्होंने इसके लिए दो स्थापित तरीकों का उपयोग किया: एक जो मानक श्रेणियों जैसे इनपुट और आउटपुट के आधार पर अनएडजस्टेड फंक्शन पॉइंट्स (unadjusted function points) को गिनता है, और दूसरा जो कॉस्मिक फंक्शन पॉइंट्स (cosmic function points) को ट्रैक करता है कि डेटा सिस्टम में कैसे आता और जाता है।
इसके बाद, उन्होंने उन्हीं हिस्सों की स्ट्रक्चरल कॉम्प्लेक्सिटी को मापा। इसमें फ्लोचार्ट के भीतर के लॉजिक का विश्लेषण करना शामिल था ताकि यह देखा जा सके कि कितने निर्णय बिंदु (decision points), लूप्स और ब्रांचिंग पथ मौजूद थे। उन्होंने इसके लिए दो अलग-अलग कॉम्प्लेक्सिटी मेट्रिक्स का उपयोग किया: एक जो कोड के स्वतंत्र पथों की संख्या को गिनता है, और दूसरा जो विभिन्न प्रकार के ब्रांच और लूप्स की संज्ञानात्मक कठिनाई (cognitive difficulty) को तौलता है। अंत में, उन्होंने इन संयुक्त मापों की तुलना प्रोजेक्ट के लिए लिखे गए कोड की वास्तविक पंक्तियों से की। यह अंतिम गणना 'ग्राउंड ट्रुथ' (ground truth) के रूप में कार्य करती थी, यानी तैयार सॉफ्टवेयर का वास्तविक आकार जिसे शोधकर्ता अनुमानित करने की कोशिश कर रहे थे।
परिणामों ने इस बात का एक स्पष्ट पैटर्न प्रकट किया कि किस फंक्शनल साइज पद्धति का उपयोग किया गया था। जब शोधकर्ताओं ने पहले फंक्शनल साइज मेथड का उपयोग किया, तो कॉम्प्लेक्सिटी मेजरमेंट्स जोड़ने से उनके अनुमानों की सटीकता में उल्लेखनीय सुधार हुआ। विशेष रूप से, उनके अनुमानों की त्रुटि दर (error rate) चौबीस प्रतिशत से घटकर बाईस प्रतिशत हो गई। यह सुझाव देता है कि इस प्रकार की फंक्शनल काउंटिंग के लिए, लॉजिक की जटिलता को जानना अनुमान को सुधारने में मदद करता है, जिससे यह वास्तविकता के करीब आता है। हालाँकि, दूसरी फंक्शनल साइज पद्धति के लिए कहानी अलग थी। जब उन्होंने कॉस्मिक फंक्शन पॉइंट्स का उपयोग किया, तो कॉम्प्लेक्सिटी मेजरमेंट्स जोड़ने से त्रुटि दर कम नहीं हुई, जो पंद्रह प्रतिशत पर स्थिर रही। इस मामले में, फंक्शनल साइज का माप पहले से ही इतना सटीक था कि अतिरिक्त कॉम्प्लेक्सिटी डेटा ने अंतिम संख्या को अधिक सटीक नहीं बनाया।
दूसरी पद्धति के लिए त्रुटि दर में सुधार की कमी के बावजूद, कॉम्प्लेक्सिटी डेटा अभी भी मूल्यवान साबित हुआ। जब शोधकर्ताओं ने कॉस्मिक फंक्शन पॉइंट्स में कॉम्प्लेक्सिटी मेजर को जोड़ा, तो उनके अनुमानों की गुणवत्ता में एक अलग तरह से सुधार हुआ। बहुत कम त्रुटि मार्जिन के भीतर आने वाले अनुमानों का प्रतिशत बहत्तर प्रतिशत से बढ़कर अस्सी प्रतिशत हो गया। इसका अर्थ यह है कि हालांकि औसत त्रुटि नहीं बदली, लेकिन टीम सही उत्तर के बहुत करीब पहुँचने में अधिक विश्वसनीय हो गई। अध्ययन निष्कर्ष निकालता है कि कॉम्प्लेक्सिटी मेजर को एकीकृत करना 'वन-साइज़-फिट्स-ऑल' (एक ही नियम सबके लिए लागू) समाधान नहीं है; इसका मूल्य इस बात पर निर्भर करता है कि किस फंक्शनल साइज मेथड का उपयोग किया जा रहा है। एक पद्धति के लिए, यह सटीकता को तेज करता है, जबकि दूसरी के लिए, यह निरंतरता (consistency) को तेज करता है। ये निष्कर्ष स्थापित एफर्ट एस्टिमेशन मॉडल्स (effort estimation models) में डेटा फीड करने का एक नया, अधिक सूक्ष्म तरीका प्रदान करते हैं, जो संभावित रूप से सॉफ्टवेयर टीमों को उनके प्रोजेक्ट्स के लिए आवश्यक समय और संसाधनों के बारे में अधिक सूचित निर्णय लेने में मदद कर सकता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।