सॉफ्टवेयर लागत अनुमान [बंद]

Question

मैंने अपने कार्य स्थान (एक विश्वविद्यालय) पर देखा है, जो अधिकांश छात्र COCOMO का उपयोग करते हुए अपने अंतिम डिप्लोमा कार्य के सॉफ्टवेयर आकलन लागत को बनाते हैं । मेरा अनुमान है कि लागत का अनुमान लगाने का यह तरीका कुछ पुराना है (1981 की COCOMO तिथियां), इसलिए मेरा प्रश्न:

How do you estimate costs in your software?

मैंने चीजों को देखा है:

लागत = (ऑवर्सऑफवर्क्स + एस्टिमेटडल) * प्रति घंटा

यह वह नहीं है जो मैं चाहता हूं, मैं ठीक से (वैज्ञानिक रूप से) परिभाषित लागत मॉडल की तलाश कर रहा हूं

EDIT मैं SO पर कुछ संबंधित प्रश्न पाया है:

• सॉफ़्टवेयर लागत अनुमान विधियों और मॉडलों में से कुछ क्या हैं?
• आप सॉफ़्टवेयर आवश्यकताओं को विकसित करने की लागत का अनुमान कैसे लगाते हैं?

Comments

"आप अपने सॉफ़्टवेयर में लागतों का अनुमान कैसे लगाते हैं?" गरीब, हर किसी की तरह ही।

— रीन हेनरिक्स

यह वास्तव में, दो प्रश्न हैं। मेरा सुझाव है कि आप इसे एक मुख्य प्रश्न के रूप में फिर से लिखें जो गूढ़ सॉफ्टवेयर पर निर्भर नहीं है। मुझे लगता है कि आपको कई जवाब मिलेंगे यदि आवश्यकता

— कोकोमो के

@ फिर, मैं आपकी सलाह लूंगा और प्रश्न को फिर से लिखूंगा ...

— डेविड कोनडे

स्टीव मैककोनेल को आईटी में बहुत सारे लोगों द्वारा इस स्थान में एक विचारशील नेता माना जाता है। आपको उनकी पुस्तक पर एक नजर डालनी चाहिए। stevemcconnell.com/est.htm

— जेफ

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह सहायता केंद्र में परिभाषित दायरे के भीतर एक वैचारिक प्रोग्रामिंग समस्या के बारे में नहीं है ।

— ड्यूर्रोन 597

Answer 1

यदि आप वाटरफॉल मोड में फंस गए हैं, तो मेरे द्वारा उपयोग की जाने वाली एकमात्र सटीक विधि है:

1. वर्क ब्रेकडाउन स्ट्रक्चर बनाएं
2. सुनिश्चित करें कि यह पर्याप्त विस्तृत है ताकि आप प्रत्येक कार्य के परिमाण को आप से कुछ (या किसी से बात कर सकें) से पहले कर सकते हैं।
3. प्रत्येक कार्य के लिए, अनुभव के आधार पर एक सर्वोत्तम-केस, संभावित-केस और सबसे खराब स्थिति वाले नंबर आते हैं। सबसे अच्छा मामला यह है कि अगर सब कुछ पूरी तरह से चला गया है, तो सबसे खराब स्थिति यह है कि अगर आपको इसे दोबारा करना पड़ा (शायद दो बार) और संभावित कहीं न कहीं है।
4. प्रत्येक कार्य के लिए एक अनुमान के साथ आने के लिए कुछ भारिंग सूत्र का उपयोग करें (1 * सर्वोत्तम + 4 * संभावित + 1 * सबसे खराब) / 6।
5. मैंने ऐसे वेरिएंट भी देखे हैं जहां आप प्रत्येक कार्य के लिए "जोखिम" घटक जोड़ सकते हैं। जोखिम के तीन स्तर 0, 1 और 2 हैं। 0 के जोखिम का मतलब है कि आपने इसे पहले (या कुछ बहुत करीबी) किया है, 1 का मतलब है कि आपने इसे पहले नहीं किया है, लेकिन यह आपके उद्योग में नियमित रूप से किया जाता है, 2 इसका मतलब है कि यह शायद उद्योग में पहले कभी नहीं किया गया है। आप जोखिम संख्या लेते हैं और अपने अनुमान के "मानक विचलन" के एक अनुमान से गुणा करते हैं। इसे अपने भारित अनुमान में जोड़ें। इसलिए 0 का जोखिम इसे स्थानांतरित नहीं करता है, लेकिन 2 का जोखिम इसे आपके सबसे खराब मामले की संख्या के काफी करीब ले जाता है।
6. सभी कार्यों को जोड़ें।
7. "अज्ञात अज्ञात" के लिए एक आकस्मिकता (कुछ%) जोड़ें।

आप एक बहुत ही सटीक संख्या के साथ समाप्त करेंगे। मैं यह नहीं कह रहा हूं कि यह सटीक है, लेकिन यह सटीक होगा।

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

जब आप प्रोजेक्ट को निष्पादित करते हैं, तो प्रत्येक कार्य के खिलाफ अपना समय ट्रैक करें, और उन लोगों को लिख दें जिन्हें आपने याद किया था, इसलिए आप तुलना कर सकते हैं। यह आपको समय के साथ बेहतर बना देगा।

Comments

धन्यवाद @ सच, ​​मैं आपके विचार की तरह कुछ सिफारिश करूंगा ..

— डेविड कोंडे

इस तरह से अपना अनुमान लगाएं, फिर स्वतंत्र रूप से दूसरे तरीके से अनुमान लगाएं (और / या दूसरा व्यक्ति अनुमान लगाता है)। परिणामों की तुलना करें। "आंत की भावना" की समीक्षा के लिए कुछ भी अलग या काफी अलग होना चाहिए। मेरा अनुभव (25 वर्ष +) यह है कि "आंत की भावना" अक्सर किसी भी फैंसी सूत्र की तुलना में अधिक सटीक होती है, इसे अपने जोखिम पर ध्यान न दें।

— मटनज़

@ मट्टनज़ - आंत की भावना में एक ही चेतावनी है: यह केवल तभी काम करता है जब आपके पास बहुत अनुभव हो। हर ग्राहक में एक "आंत की भावना" होती है, जो कि उसकी तुलना में बहुत कम खर्च करने वाली है, क्योंकि वे कोने के मामलों में शामिल काम की मात्रा को नहीं समझते हैं।

— स्कॉट व्हिटलॉक

एक और टिप: "मैं अनुमानों पर बातचीत नहीं करता। <लंबे ठहराव>" मालिकों / ग्राहकों के साथ बैठकों में एक बहुत ही उपयोगी वाक्यांश है। आखिरकार, आपकी कार मैकेनिक या सर्जन क्या करता है? वह कीमत पर बातचीत कर सकता है, वह बातचीत कर सकता है कि क्या काम किया जाता है या यह कैसे किया जाता है, लेकिन मैंने कभी भी किसी ट्रेड के लिए किसी ट्रेडर को सॉफ्टवेयर बातचीत के अलावा किसी भी क्षेत्र में पेशेवर के लिए नहीं देखा है।

— मटनज

@mattnz - मैंने पिछले हफ्ते एक कार मैकेनिक के साथ बातचीत की कि मेरी कार के दरवाजे की मरम्मत में कितना समय लगेगा, यह कैसे किया गया।

— साठफुटेरसूड

Answer 2

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

Comments

सबसे सफल अनुमान जो मैंने देखा है (परिष्कृत तरीकों का उपयोग करने वालों सहित नहीं) वे हैं जो मूल अनुमान को दोगुना कर देते हैं।

— बर्नार्ड डा

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

— डेव

Answer 3

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

Answer 4

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

यदि आपके पास एक अच्छा मॉडल है, तो काम करने के लिए डेटा का एक अच्छा सेट प्राप्त करना बहुत मुश्किल है। उत्पादकता को मापना कठिन है। लोग लगभग किसी भी मीट्रिक खेल।

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

Answer 5

प्रयासों और लागतों का अनुमान लगाना बहुत मुश्किल है, लेकिन यदि आप कुछ अधिक सटीक चाहते हैं, तो:

• ऑवर्सऑवरवर्क्स को 3 घटकों में विभाजित करें:

  1. सबसे अच्छा अनुमान,
  2. सबसे अधिक संभावना अनुमान,
  3. बुरा अनुमान।

• अनुमान हटाएं।

ध्यान दें कि 8 घंटे से अधिक समय लेने वाली कोई भी चीज भारी त्रुटि पेश करेगी।

Answer 6

हम सामान्य रूप से पूर्ण कार्य क्षेत्र को प्रमुख मॉड्यूल / तत्वों में विभाजित कर रहे हैं जिन्हें उप-परियोजना माना जा सकता है। दूसरे शब्दों में, वे काम के हिस्से हैं जो ग्राहक परियोजना के अलग-अलग हिस्सों के रूप में मानते हैं और कौन से ग्राहक अलग से अनुमान लगाना चाहते हैं।

एक बार जब यह हो जाता है तो हम प्रत्येक मॉड्यूल को कार्यों, उप-कार्यों और यहां तक ​​कि छोटे उप-उप-कार्यों में विभाजित करते हैं, ताकि प्रत्येक को काफी आसान अनुमान लगाया जा सके और अनुमान एक से दस आदमी-घंटे लगते हैं। इस तरह से हमें परियोजना के लिए काम की गुंजाइश टूटने लगी है।

अंतिम चरण मील के पत्थर के बीच कार्यों को वितरित कर रहा है। हम इसे वैसे ही करते हैं ताकि प्रत्येक मील के पत्थर के ग्राहक को दृश्यमान परिणाम मिले। जो एक मील के पत्थर को पास करने और दूसरे को स्थानांतरित करने में मदद करता है। तो अंत में हमें कुछ ऐसा मिलता है:

मॉड्यूल 1

    <ol>
        <li>
            Primary task 1 - 5 hrs
            <ol>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

प्रारंभ में हमने इसे एक्सेल शीट का उपयोग करके किया था। लेकिन दो साल से अधिक समय पहले हमने इसके लिए सॉफ्टवेयर टूल का इस्तेमाल शुरू किया था। कुछ ऐसे ही उत्पाद हैं जो इसके साथ मदद करते हैं www.evenflow.com , www.swproposal.com और कुछ अन्य। मुझे सारी सूची याद नहीं है। हमने बहुत पहले शोध किया था। उम्मीद है कि मदद मिल सकती है।

अच्छा सवाल यह है कि सटीक अनुमान कैसे लगाया जाए। जैसा कि हम मानते हैं कि कोई 100% सही अनुमान नहीं है। एकमात्र तरीका यह है कि पूर्ण कार्यक्षेत्र को यथासंभव छोटे कार्यों में विभाजित किया जाए। आपके द्वारा किए गए प्रोजेक्ट की अधिक विस्तृत समीक्षा और विश्लेषण आपके द्वारा किए गए छोटे कार्य हैं। ताकि किसी भी तरह सटीकता बढ़े।