GitReq: A Gold Standard Dataset for Software Quality Requirements
यह शोध पत्र GitReq को प्रस्तुत करता है, जो आठ ISO/IEC 25010:2011-अनुरूप सॉफ्टवेयर गुणवत्ता आवश्यकताओं में वर्गीकृत 6,302 विशेषज्ञ-सत्यापित GitHub इश्यू का एक सार्वजनिक रूप से उपलब्ध डेटासेट है, जो स्वचालित आवश्यकता वर्गीकरण और सॉफ्टवेयर गुणवत्ता विश्लेषण को आगे बढ़ाने के लिए एक गोल्ड स्टैंडर्ड के रूप में कार्य करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, अराजक पुस्तकालय में जा रहे हैं जहाँ लाखों लोगों ने अलमारियों पर स्टिकी नोट्स (sticky notes) छोड़ दिए हैं। ये नोट्स केवल साधारण शिकायतें नहीं हैं; ये दुनिया के सॉफ्टवेयर के डेवलपर्स हैं जो अपनी रचनाओं को बेहतर ढंग से कैसे काम करना चाहिए, इस बारे में फुसफुसा रहे हैं (या चिल्ला रहे हैं)। कुछ कहते हैं, "यह ऐप बहुत धीमा है!" (परफॉरमेंस/प्रदर्शन)। अन्य कहते हैं, "हमें दरवाजे पर एक बेहतर ताला चाहिए!" (सुरक्षा)। कुछ कहते हैं, "इसे मेरे पुराने फोन पर भी काम करना चाहिए!" (पोर्टेबिलिटी/सुवाह्यता)।
समस्या यह है कि ये नोट्स एक गड़बड़ ढेर हैं। ये आपस में मिले हुए हैं, स्लैंग (slang) में लिखे गए हैं, और बग्स, सवालों और फीचर अनुरोधों के लाखों अन्य नोट्स के नीचे दबे हुए हैं। अब तक, किसी ने भी इन विशिष्ट "क्वालिटी" नोट्स को एक व्यवस्थित, लेबल किए गए संग्रह में व्यवस्थित नहीं किया था ताकि शोधकर्ता इनका अध्ययन कर सकें।
GitReq से मिलिए: महान लाइब्रेरियन (The Great Librarian)।
इस शोध पत्र के लेखकों ने GitReq बनाया है, जो एक "गोल्ड स्टैंडर्ड" डेटासेट है। इसे एक सावधानीपूर्वक व्यवस्थित संग्रह के रूप में सोचें जिसमें 6,302 ऐसे डेवलपर नोट्स हैं, जिन्हें GitHub पर 4,000 से अधिक विभिन्न सॉफ्टवेयर प्रोजेक्ट्स से निकाला गया है।
उन्होंने इसे कैसे किया, यहाँ सरल चरणों में दिया गया है:
1. खजाने की खोज (माइनिंग)
टीम ने केवल रैंडम नोट्स नहीं उठाए। उन्होंने सही नोट्स खोजने के लिए एक "तीन-संकेत" (three-signal) रणनीति का उपयोग किया। कल्पना कीजिए कि आप तालाब में एक विशिष्ट प्रकार की मछली की तलाश कर रहे हैं:
- संकेत 1: उन्होंने सही "फ्लैग" (एक लेबल जो डेवलपर ने पहले से ही नोट पर लगाया था, जैसे "Security") की तलाश की।
- संकेत 2: उन्होंने जाँच की कि क्या नोट वास्तव में किसी नई चीज़ के लिए अनुरोध था (जैसे "Feature Request" या "Enhancement" जैसे लेबल), और उन नोट्स को अनदेखा किया जो केवल बग रिपोर्ट या सवाल थे।
- संकेत 3: उन्होंने विशिष्ट कीवर्ड्स (जैसे "slow," "hack," या "crash") के लिए टेक्स्ट को स्कैन किया।
उन्होंने 55,588 संभावित नोट्स से शुरुआत की। यह कागज का एक बहुत बड़ा ढेर है!
2. सॉर्टिंग मशीन (प्रीप्रोसेसिंग)
इससे पहले कि इंसान उन्हें पढ़ पाते, टीम ने दो अलग-अलग "सॉर्टिंग मशीनें" बनाईं क्योंकि नोट्स दो बहुत ही अलग स्वादों में आए थे:
- "NFR" मशीन (नॉन-फंक्शनल रिक्वायरमेंट्स): ये वे नोट्स हैं जो इस बारे में हैं कि सिस्टम कैसे व्यवहार करता है (गति, सुरक्षा, विश्वसनीयता)। ये नोट्स अक्सर छोटे, अव्यवस्थित और स्लैंग-प्रधान होते हैं (जैसे, "जब 100 लोग लॉग इन करते हैं तो सर्वर क्रैश हो जाता है")। मशीन ने शोर को साफ किया लेकिन वास्तविक दुनिया की भाषा को बरकरार रखा।
- "FR" मशीन (फंक्शनल रिक्वायरमेंट्स): ये वे नोट्स हैं जो इस बारे में हैं कि सिस्टम को क्या करना चाहिए (जैसे, "सिस्टम को उपयोगकर्ताओं को फाइलें सहेजने की अनुमति देनी चाहिए")। इन्हें बहुत विशिष्ट होना चाहिए। मशीन सख्त थी: यदि नोट एक औपचारिक नियम की तरह नहीं लगता था (जैसे "must," "shall," या "user story" जैसे शब्दों का उपयोग), तो उसे बाहर कर दिया गया। इसने यह सुनिश्चित किया कि वे गलती से अस्पष्ट फीचर विचारों को शामिल न कर लें।
3. विशेषज्ञ पैनल (ह्यूमन एनोटेशन)
मशीनों द्वारा अपना काम करने के बाद, उनके पास अभी भी लगभग 8,500 नोट्स बचे थे। यहीं पर मानवीय जादू हुआ।
- जज: सॉफ्टवेयर इंजीनियरिंग के सात विशेषज्ञों ने इन नोट्स को पढ़ने के लिए समय बिताया।
- प्रशिक्षण: उन्होंने घंटों तक नियमों को सीखने में बिताया, जिसका उपयोग करने के लिए एक मानक मार्गदर्शिका का उपयोग किया गया जिसे ISO/IEC 25010 कहा जाता है। इसे एक नियम पुस्तिका के रूप में सोचें जो परिभाषित करती है कि "Security" का अर्थ "Scalability" से क्या अलग है।
- फैसला: उन्होंने प्रत्येक नोट को आठ श्रेणियों में लेबल किया: Performance, Security, Portability, Availability, Fault-tolerance, Scalability, Maintainability, और Functional।
- सहमति: उन्होंने केवल अनुमान नहीं लगाया। उन्होंने एक-दूसरे के काम की जाँच की। जब वे असहमत हुए, तो वे आपस में चर्चा करके सहमत हुए। परिणाम एक बहुत ही उच्च स्तर की सहमति (0.72 का स्कोर) थी, जिसका अर्थ है कि लेबल भरोसेमंद हैं।
4. अंतिम संग्रह
मूल 55,000+ उम्मीदवारों में से, उनके पास 6,302 उच्च-गुणवत्ता वाले, विशेषज्ञ-सत्यापित नोट्स बचे।
- मिश्रण: लगभग आधा सुरक्षा (Security) और प्रदर्शन (Performance) के बारे में है (सबसे आम चिंताएं)।
- विविधता: वे वेब फ्रेमवर्क से लेकर मोबाइल ऐप्स और क्लाउड सिस्टम तक सब कुछ कवर करते हैं।
- प्रमाण: उन्होंने इस नए डेटासेट का परीक्षण चार शक्तिशाली AI मॉडल (जैसे GPT-5.2) के विरुद्ध भी किया। AI मॉडल थोड़ा संघर्ष करते हैं, विशेष रूप से "Maintainability" जैसी कठिन श्रेणियों के साथ, जो यह साबित करता है कि यह डेटासेट भविष्य के AI टूल्स के लिए एक कठिन, वास्तविक परीक्षण है।
यह क्यों मायने रखता है?
इससे पहले, शोधकर्ता जो कंप्यूटर को सॉफ्टवेयर क्वालिटी समझने के लिए सिखाने की कोशिश कर रहे थे, उन्हें छोटे, पुराने डेटासेट्स या औपचारिक दस्तावेजों का उपयोग करना पड़ता था जो वास्तविक जीवन जैसा नहीं दिखता था। यह वैसा ही था जैसे 1990 में लिखे गए टेक्स्टबुक को पढ़कर कार चलाना सीखने की कोशिश करना।
GitReq शोधकर्ताओं को एक बिल्कुल नया, वास्तविक दुनिया का ड्राइविंग सिम्युलेटर देने जैसा है। यह उन्हें बेहतर AI टूल बनाने की अनुमति देता है जो वास्तव में उस अव्यवस्थित, वास्तविक बातचीत को समझ सकते हैं जो डेवलपर्स हर दिन करते हैं, जिससे गुणवत्ता संबंधी समस्याओं को तेजी से और अधिक सटीकता से पहचाना जा सके।
संक्षेप में: इस शोध पत्र ने केवल घास के ढेर में सुई नहीं ढूँढी; उन्होंने सुइयों का एक पूरा नया पुस्तकालय बनाया, उन्हें प्रकार के अनुसार छाँटा, और दुनिया को उन्हें खोजने के लिए एक नक्शा दिया।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।