आप सॉफ्टवेयर में विश्वसनीयता का मूल्यांकन कैसे करते हैं?

Question

वर्तमान में हम एक व्यापार अध्ययन के लिए मूल्यांकन मानदंड स्थापित कर रहे हैं जो हम करेंगे।

हमारे द्वारा चुने गए मानदंड में से एक विश्वसनीयता (और/या मजबूती - ये वही हैं?)।

आप कैसे मूल्यांकन करते हैं कि सॉफ्टवेयर का मूल्यांकन करने में अधिक समय बर्दाश्त किए बिना विश्वसनीय है?

संपादित करें: प्रश्न के फोकस को कम करने के लिए केनजी द्वारा दी गई प्रतिक्रिया की पंक्तियों के साथ: आप 50 मौजूदा सॉफ़्टवेयर समाधानों में से एक चुन सकते हैं। आपको यह आकलन करने की आवश्यकता है कि वे कितने विश्वसनीय हैं, उन्हें परीक्षण करने में सक्षम होने के बिना (कम से कम शुरुआत में)। क्या मूर्त मेट्रिक्स या अन्य आप उपयोग की विश्वसनीयता का मूल्यांकन करने के लिए उपयोग कर सकते हैं?

Answer 1

विश्वसनीयता और मजबूती एक sytem के दो अलग-अलग गुण हैं:

Reliability

आईईईई के रूप में "एक सिस्टम या के घटक के क्षमता के तहत अपने आवश्यक कार्य करते हैं यह परिभाषित करता है।।। निर्दिष्ट समय के लिए शर्तों को बताया गया। "

Robustness

, अगर यह इनपुट, गणना में असामान्यताएं के बावजूद संचालित करने के लिए जारी है मजबूत है आदि

तो एक विश्वसनीय प्रणाली अपनी कार्य करता है के रूप में यह भीतर करने के लिए डिजाइन किया गया था की कमी; अप्रत्याशित/अप्रत्याशित होने पर मजबूत सिस्टम चालू रहता है।

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

क्या उत्पाद में स्वचालित परीक्षण प्रक्रियाएं हैं? टेस्ट कवरेज आत्मविश्वास का एक और संकेत हो सकता है।

कुछ चुस्त तरीकों का उपयोग कर अच्छी तरह से इन मानदंड के अनुरूप नहीं हो सकता है परियोजनाओं - लगातार विज्ञप्ति और पुनर्रचना का एक बहुत उम्मीद कर रहे हैं असली दुनिया में जानकारी के लिए सॉफ्टवेयर/उत्पाद की मौजूदा उपयोगकर्ताओं के साथ

चेक।

Answer 2

अच्छा, कीवर्ड 'विश्वसनीय' अलग-अलग उत्तरों का कारण बन सकता है ... विश्वसनीयता के बारे में सोचते समय, मुझे दो पहलुओं के बारे में लगता है: 1 ~ हमेशा सही उत्तर (या सबसे अच्छा जवाब) 2 ~ हमेशा देना एक ही जवाब

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

तथ्य यह है कि परीक्षण हमेशा एक ही परिणाम लौटाते हैं, यह दिखाएगा कि पहलू # 2 का ख्याल रखा जाता है। पहलू # 1 के लिए यह वास्तव में परीक्षण लेखकों पर निर्भर है: अच्छे परीक्षणों के साथ आना जो बग या अपूर्णताओं का पर्दाफाश करेंगे।

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

Answer 3

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

Answer 4

यह इस बात पर निर्भर करता है कि आप किस प्रकार के सॉफ्टवेयर का मूल्यांकन कर रहे हैं। विश्वसनीयता के लिए वेबसाइट की मुख्य (और शायद केवल) मानदंड इसकी अपटाइम हो सकती है। NASA के अपने सॉफ्टवेयर की विश्वसनीयता के लिए एक पूरी तरह से अलग परिभाषा होगी। आपकी परिभाषा शायद कहीं बीच में होगी।

यदि आपके पास विश्वसनीयता का मूल्यांकन करने के लिए बहुत समय नहीं है, तो यह बिल्कुल महत्वपूर्ण है कि आप अपनी माप प्रक्रिया स्वचालित करते हैं। आप यह सुनिश्चित करने के लिए continuous integration उपकरण का उपयोग कर सकते हैं कि आपको केवल एक बार मैन्युअल रूप से एक बग मिलना होगा।

मैं आपको सलाह देता हूं कि आपकी कंपनी में कोई या Continuous Integration: Improving Software Quality and Reducing Risk पढ़े। मुझे लगता है कि यह आपको सॉफ्टवेयर विश्वसनीयता की अपनी परिभाषा में ले जाने में मदद करेगा।

Answer 5

आपको समझने और पूरी तरह स्वीकार करने की प्रक्रिया में जाना होगा कि आप एक समझौता करेंगे, जो नकारात्मक प्रभाव हो सकता है यदि विश्वसनीयता एक महत्वपूर्ण मानदंड है और आपके पास (या प्रतिबद्ध करने के इच्छुक नहीं हैं) संसाधनों के आधार पर उचित मूल्यांकन करने के लिए।

यह कहकर - यह निर्धारित करें कि प्रमुख आवश्यकताएं क्या हैं जो सॉफ़्टवेयर विश्वसनीयता को महत्वपूर्ण बनाती हैं, फिर उन आवश्यकताओं के आधार पर मूल्यांकन करने के लिए परीक्षण तैयार करें।

मजबूती और विश्वसनीयता एक दूसरे के साथ अपने रिश्ते में पार हो जाती है, लेकिन यह आवश्यक नहीं है।

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

मेरा सुझाव यह है कि आप एक अनुभवी क्यूए व्यक्ति से परामर्श लें जो अध्ययन के लिए क्षेत्र में जानकार है। वह व्यक्ति महत्वपूर्ण संसाधनों के लिए परीक्षण तैयार करने में आपकी सहायता करने में सक्षम होगा - आपकी संसाधन बाधाओं के भीतर। मैं आपके दृढ़ संकल्प के लिए परीक्षण करने के लिए आवश्यक प्रमुख विशेषताओं पर निर्णय लेने में आपकी सहायता के लिए एक तटस्थ तृतीय पक्ष (सॉफ़्टवेयर लेखक या विक्रेता की बजाय) की अनुशंसा करता हूं।

Answer 6

किसी भी चीज़ के साथ, यदि आपके पास कुछ स्वयं का आकलन करने का समय नहीं है, तो आपको दूसरों के फैसले पर भरोसा करना होगा।

Answer 7

विश्वसनीयता somethings 'प्रभावशीलता .. अन्य दो अनुरक्षणीयता और उपलब्धता रहे हैं के तीन पहलुओं में से एक ...

एक दिलचस्प कागज ... और अधिक विस्तार में http://www.barringer1.com/pdf/ARMandC.pdf चर्चा इस है, लेकिन आम तौर पर,

है विश्वसनीयता उस संभावना पर आधारित है जो एक प्रणाली टूट जाएगी .. यानी, इसे तोड़ने की अधिक संभावना है, कम विश्वसनीय यह है ...अन्य प्रणालियों में (सॉफ़्टवेयर के अलावा) इसे अक्सर विफलता के बीच मीन टाइम में मापा जाता है (एमटीबीएफ) यह हार्ड डिस्क जैसी चीजों के लिए एक आम मीट्रिक है ... (10000 बजे एमटीबीएफ) सॉफ़्टवेयर में, मुझे लगता है कि आप इसे माप सकते हैं महत्वपूर्ण सिस्टम विफलताओं, या अप्रत्याशित त्रुटियों के बीच, या किसी भी प्रकार की त्रुटियों के बीच जो सामान्य सिस्टम उत्पादकता को बाधित या प्रतिकूल रूप से प्रभावित करता है ...

रखरखाव कितना लंबा/कितना महंगा है (कितने मैन-घंटे और/या अन्य संसाधन) इसे तोड़ने पर इसे ठीक करने में लगते हैं। सॉफ़्टवेयर में, आप इस अवधारणा को जोड़ सकते हैं कि सॉफ़्टवेयर को बढ़ाने या बढ़ाने के लिए कितना महंगा/कितना महंगा है (यदि यह एक चल रही आवश्यकता है)

उपलब्धता पहले दो का संयोजन है, और एक योजनाकार को इंगित करता है, अगर असफलताओं को समझने के बाद मेरे पास इनमें से 100 चीजें चल रही थीं और कितनी देर तक प्रत्येक असफल इकाई अनुपलब्ध थी, जब तय की जा रही थी, मरम्मत की गई थी, जो भी हो, 100 में से कितने औसतन, किसी भी पर चल रहे होंगे एक बार? 20%, या 98%?

Answer 8

यदि आप इसका परीक्षण नहीं कर सकते हैं, तो आपको डेवलपर की प्रतिष्ठा पर भरोसा करना होगा कि साथ ही उन्होंने इस एप्लिकेशन पर उनके अन्य परीक्षण किए गए ऐप्स के समान अभ्यासों का पालन किया है। उदाहरण: माइक्रोसॉफ्ट अपने अनुप्रयोगों के संस्करण 1 के साथ बहुत अच्छा काम नहीं करता है, लेकिन 3 & 4 आमतौर पर बहुत अच्छे होते हैं (विंडोज एमई संस्करण 0.0001 था)।

Answer 9

आपके द्वारा मूल्यांकन की जाने वाली सेवा के प्रकार के आधार पर, आपको विश्वसनीयता मेट्रिक्स या एसएलआई - सेवा स्तर संकेतक मिल सकते हैं - मेट्रिक्स कैप्चरिंग कि सेवा/उत्पाद कितनी अच्छी तरह से कर रहा है। उदाहरण के लिए - 1sec के तहत 99% अनुरोधों को संसाधित करें।

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