क्या परियोजना अनुमान के लिए एलओसी सही पैरामीटर है?

Question

क्या परियोजना अनुमान के लिए एलओसी सही पैरामीटर है?

ऐसे कई परिदृश्य हैं जहां जटिलता को कोड की एक पंक्ति के लिए अधिक समय लगता है, एलओसी के अलावा अन्य परियोजना अनुमान के लिए सुझाए गए पैरामीटर क्या हो सकता है?

जैसे लोग प्रोग्राम के कार्यात्मक बिंदु के बारे में बात कर रहे हैं, इसका मतलब केस से संबंधित जानकारी के लिए है?

मैं पूर्ण सॉफ्टवेयर विकास अनुमान के लिए कोई ठोस आधार खोजने की कोशिश कर रहा हूं जिसमें विश्लेषण, डिज़ाइन, टेस्टकेस तैयारी और कोडिंग शामिल हो सकती है, कृपया सुझाव दें?

Answer 1

केवल अगर आप इसे उलटा में उपयोग करते हैं।

-

लेकिन नहीं। यह नहीं है यह ज्यादातर बेकार उपाय है, और आम तौर पर हानिकारक है। जैसा कि आप ध्यान देते हैं, कम कोड लगभग हमेशा बेहतर है।

अन्य चीजों को जांचने के लिए? खैर, आप क्या मापने की कोशिश कर रहे हैं? आप जिस चीज की जांच करेंगे, उसमें बदलाव से आप क्या परिणाम देखना चाहते हैं? इन परिवर्तनों के आधार पर आप किस तरह के निर्णय ले रहे होंगे?

Answer 2

रैपिड विकास में

स्टीव McConnell (माइक्रोसॉफ्ट प्रेस, 1996):

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

अधिक जानकारी के लिए Google "फंक्शन प्वाइंट"।

Answer 3

LOC समस्या आकार को मापने के लिए एक प्रॉक्सी उपाय है।

एलओसी अनुमान का उपयोग किया जा सकता है, और ऐतिहासिक परियोजनाओं से मापने के लिए एलओसी गणना अपेक्षाकृत सस्ते है। लेकिन एलओसी समस्याग्रस्त हो सकता है अगर समस्या के आकार के लिए प्रॉक्सी से किसी और चीज के लिए इस्तेमाल किया जाता है, जैसा कि पहले से ही अन्य उत्तरों द्वारा इंगित किया गया है।

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

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

Answer 4

डेवलपर्स के रूप में देखकर * अधिकतर समय परिवर्तनों का परीक्षण करने की कोशिश कर रहे हैं, लाइन-ऑफ-कोड किसी समस्या के आकार का एक अच्छा संकेतक नहीं है।

मान लीजिए कि आपके पास एक बड़ा बड़ा एप्लीकेशन है - कोड की एक पंक्ति को बदलना तुच्छ लग सकता है, लेकिन परीक्षण योजना और निष्पादन में सप्ताह लग सकते हैं।

इसी प्रकार, एक सीमित-स्कोप मॉड्यूल में अपेक्षाकृत बड़ी मात्रा में कोड जोड़ना जो आसानी से परीक्षण योग्य हो सकता है केवल कुछ ही दिन हो सकता है।

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

Answer 5

नहीं, यह नहीं है। कारण सरल है: यदि आप अपने विकास के दौरान कोड की एक नई पंक्ति तैयार करते हैं, तो क्या आप समाधान के करीब एक कदम हैं? यदि आपने कार्य पूरा करने के लिए कोड की 1000 पंक्तियों का अनुमान लगाया है, तो क्या आप अब उस कार्य के साथ 0.1% पूर्ण हैं?

कोड की रेखाओं को मीट्रिक के रूप में उपयोग किया जा सकता है लेकिन केवल नकारात्मक अर्थ में: कोड की अधिक संख्या के लिए, यह मानना ​​उचित है कि आपके पास बड़ी संख्या में बग हैं। ऐतिहासिक डेटा के आधार पर, आमतौर पर कोड और बग गिनती के बीच एक रैखिक सहसंबंध होता है। श्रम की

1. घंटे:

   यहाँ कुछ उपयोगी और औसत दर्जे का कारक है कि विचार के लायक हैं कर रहे हैं।

2. डॉलर बिताए: यह एक अच्छा है क्योंकि यह दृढ़ता से इस वास्तविकता को लागू करता है कि आप डेवलपर के डेस्कटॉप पर एक परीक्षक या ग्राहक के हाथों की तुलना में बग पा सकते हैं)।
3. मील का पत्थर मिले: क्या सिस्टम सही तारीख पर ग्राहकों के लिए उपलब्ध है?
4. आवश्यकताएं पूरी हुईं: यह एक मजेदार हो सकता है - यदि आप परियोजना के दौरान एक नई ग्राहक आवश्यकता की खोज करते हैं तो क्या होगा?

संक्षेप में, कोड की लाइनें बहुत लगभग सबसे खराब संभव मीट्रिक क्या तुमने कभी इस्तेमाल कर सकते हैं है।

Answer 6

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