failure mode effects analysis how analyze risks
विफलता मोड और प्रभाव विश्लेषण (FMEA) एक जोखिम प्रबंधन तकनीक है।
अगर इसे सही तरीके से लागू किया जाए, तो यह एक बेहतरीन अतिरिक्त हो सकता है गुणवत्ता आश्वासन प्रक्रियाएं पालन किया जाएगा। इस लेख में, हमारा लक्ष्य आपको इस जोखिम विश्लेषण तकनीक से परिचित कराना है, जो अंत में, सॉफ़्टवेयर की गुणवत्ता में सुधार के लिए बहुत उपयोगी है।
आप क्या सीखेंगे:
- विफलता मोड और प्रभाव विश्लेषण
- जोखिम विश्लेषण क्या है?
- विफलता मोड प्रभाव विश्लेषण उदाहरण
- FMEA और परीक्षण की डिग्री
- निष्कर्ष
- अनुशंसित पाठ
विफलता मोड और प्रभाव विश्लेषण
FMEA का उपयोग ज्यादातर ऊपरी प्रबंधन या हितधारकों द्वारा किया जाता है। व्यवहार में, परीक्षकों को इस तकनीक में बहुत कम जानकारी मिलती है। लेकिन अब ट्रेंड बदल रहा है और मुझे लगता है कि अगर परीक्षार्थी इस अवधारणा को ठीक से समझें तो वे ऐसा कर सकते हैं की उनकी सोचा प्रक्रिया ड्राइव परीक्षण के मामले लिखना इस तकनीक का उपयोग करके एक स्तर तक:
- आवेदन के परीक्षण के हितधारक के लक्ष्यों को समझें।
- व्यवसाय को समझें।
- व्यवसाय और प्रबंधन रुचि के आधार पर उच्च-स्तरीय परीक्षण परिदृश्यों को प्राप्त करें।
- प्रभावी प्रभावी परीक्षण मामले जो जोखिम-ग्रस्त क्षेत्रों को बेहतर कवरेज प्रदान करते हैं।
- परीक्षण मामलों को प्राथमिकता दें।
- तय करें कि क्या परीक्षण करना है और किसी भी चरण में क्या हो सकता है।
पृष्ठभूमि
जोखिम विश्लेषण का एक महत्वपूर्ण पहलू है परीक्षण प्रबंधन । फिर सवाल उठता है - जोखिम विश्लेषण क्या है? और यह महत्वपूर्ण क्यों है? इसे समझने के लिए, यह समझना महत्वपूर्ण है - जोखिम क्या है?
यह भी देखें => सॉफ्टवेयर परियोजनाओं में जोखिम के प्रकार।
इसके शाब्दिक अर्थ के रूप में जोखिम एक नकारात्मक या अवांछनीय परिणाम या घटना की संभावना है। यदि संभाला नहीं जाता है या ठीक से प्रबंधित नहीं किया जाता है तो खराब गुणवत्ता, असंतुष्ट ग्राहक और कभी-कभी व्यापार में नुकसान हो सकता है।
जोखिम में 2 विशेषताएं हैं:
- संभावना
- प्रभाव
संभाव्यता का अर्थ है किसी विशेष जोखिम की संभावना और प्रभाव का मतलब जोखिम के प्रभाव की सीमा।
जोखिम विश्लेषण क्या है?
जोखिम विश्लेषण एक ऐसा तंत्र है जिसके द्वारा संभाव्यता और प्रभाव को खोजने के लिए पहचाने गए संभावित जोखिमों का विश्लेषण और गहन अध्ययन किया जाता है। यह दो विशेषताओं को मापने के लिए सलाह दी जाती है और हमारे द्वारा पहचाने जाने वाले परिणाम के आधार पर:
लिंक्ड सूची नोड सी ++
- पहले क्या टेस्ट करें?
- अधिक परीक्षण करने के लिए क्या?
- क्या परीक्षण नहीं करना है (इस बार)?
जोखिम विश्लेषण करने के कई तरीके हैं और उन्हें मोटे तौर पर दो प्रकारों में वर्गीकृत किया जाता है:
- अनौपचारिक तकनीक : ये अनुभव, निर्णय और अंतर्ज्ञान पर आधारित हैं।
- औपचारिक तकनीक : जोखिम विशेषताओं की पहचान करना और उनका वजन करना।
एफ बीमारी म ode और है नफ़्स सेवा मेरे nalysis (FMEA): यह एक जोखिम विश्लेषण करने की एक औपचारिक विधि है। निम्नलिखित अनुभागों में, मैं और अधिक चर्चा करूंगा FMEA और उदाहरण के साथ इसे विस्तृत करने का प्रयास करें।
FMEA जोखिम विश्लेषण करने की एक औपचारिक तकनीक है। यह स्प्रेड शीट के रूप में एक व्यवस्थित और मात्रात्मक उपकरण है जो सदस्यों को यह विश्लेषण करने के लिए आश्वस्त करता है कि क्या गलत हो सकता है। FMEA करने के लिए हमें टेबल पर सही लोगों की आवश्यकता होती है। इसमें ग्राहकों सहित उद्योग के सभी क्षेत्रों के प्रतिनिधि की आवश्यकता होती है।
विवरण
FMEA बुद्धिशीलता सत्र के साथ शुरू और जारी है। प्रतिभागियों को सभी घटकों, मॉड्यूल, निर्भरता, सीमाओं की पहचान करने की आवश्यकता होती है जो उत्पादन के माहौल में विफल हो सकते हैं और अंततः खराब गुणवत्ता, विश्वसनीयता का कारण बन सकते हैं और इसके परिणामस्वरूप व्यवसाय का नुकसान हो सकता है।
FMEA के दौरान हम न केवल नुकसान की सीमा की पहचान करते हैं, बल्कि उन विफलताओं के कारण की पहचान करने का भी प्रयास करते हैं। FMEA को मापने के लिए, हमें 3 विशेषताओं की आवश्यकता है:
- तीव्रता की विफलता (एस)
- वरीयता की विफलता (पी)
- संभावना की विफलता (एल)
हम नीचे दिखाए गए पैमाने में इनमें से प्रत्येक गुण रखते हैं:
गंभीरता स्केल:
विवरण | कक्षा | स्केल |
डेटा, हार्डवेयर या सुरक्षा समस्याओं का नुकसान | अति आवश्यक | 1 |
एक वर्कअराउंड के बिना कार्यक्षमता का नुकसान | उच्च | दो |
वर्कअराउंड के साथ कार्यक्षमता का नुकसान | मध्यम | ३ |
कार्यक्षमता का आंशिक नुकसान | कम | ४ |
कॉस्मेटिक या तुच्छ | कोई नहीं | ५ |
प्राथमिकता का पैमाना:
विवरण | कक्षा | स्केल |
सिस्टम वैल्यू का पूरा नुकसान | अति आवश्यक | 1 |
सिस्टम मूल्य का अस्वीकार्य नुकसान | उच्च | दो |
संभवतः सिस्टम मूल्य में कमी | मध्यम | ३ |
सिस्टम मूल्य की स्वीकार्य कमी | कम | ४ |
सिस्टम मूल्य में एक नगण्य कमी | कोई नहीं | ५ |
संभावना पैमाने:
विवरण | कक्षा | स्केल |
सभी उपयोगकर्ताओं को प्रभावित करने के लिए निश्चित है | अति आवश्यक | 1 |
कुछ उपयोगकर्ताओं को प्रभावित करने की संभावना है | बहुत ऊँचा | दो |
कुछ उपयोगकर्ताओं पर संभावित प्रभाव | उच्च | ३ |
कुछ उपयोगकर्ताओं के लिए सीमित प्रभाव | कम | ४ |
वास्तविक उपयोग में अकल्पनीय | कोई नहीं | ५ |
इन तीनों विशेषताओं (गंभीरता, प्राथमिकता और संभावना) को व्यक्तिगत रूप से बड़े पैमाने पर मापा जाता है और फिर एक प्राप्त करने के लिए गुणा किया जाता है जोखिम प्राथमिकता संख्या (RPN)।
अर्थात। पूर्व संख्या का जोखिम ( आरपीएन) = एस * पी * एल
इस RPN मूल्य के आधार पर, हम परीक्षण की सीमा निर्धारित करते हैं। कम RPN है, उच्च जोखिम है।
आइए इसे एक उदाहरण से समझने की कोशिश करें:
विफलता मोड प्रभाव विश्लेषण उदाहरण
(यह केवल एक समझ के उद्देश्य के लिए एक काल्पनिक उदाहरण है। वास्तविक कार्यान्वयन और विशेषताएं भिन्न हो सकती हैं)
आइए बैंकिंग एप्लिकेशन के एक सरल उदाहरण पर विचार करें जिसमें 4 विशेषताएं हैं।
- सुविधा 1: निकालना
- फ़ीचर 2: जमा
- फ़ीचर 3: गृह ऋण
- फ़ीचर 4: फिक्स्ड डिपॉजिट।
एक जोखिम विश्लेषण टीम बनाई गई है जिसमें बैंक प्रबंधक शामिल हैं, UAT टेस्ट मैनेजर (एंड-यूज़र का प्रतिनिधित्व), टेक्निकल आर्किटेक्ट, टेस्ट आर्किटेक्ट, नेटवर्क एडमिनिस्ट्रेटर, डीबीए और एक प्रोजेक्ट मैनेजर।
कई सत्रों के मंथन के बाद टीम साथ आई निम्नलिखित जोखिम:
- जटिल व्यावसायिक तर्क होम लोन की ब्याज दर की गणना के मामले में।
- 200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है।
- सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं।
अब आइए इन पहचाने गए जोखिमों की गंभीरता, प्राथमिकता और संभावना की गणना करने का प्रयास करें।
तीव्रता:
फ़ीचर | कक्षा | स्केल |
होम लोन की ब्याज दर की गणना के मामले में जटिल व्यावसायिक तर्क | बहुत ऊँचा | दो |
200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है | उच्च | ३ |
सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं | बहुत ऊँचा | दो |
प्राथमिकता:
फ़ीचर | कक्षा | स्केल |
होम लोन की ब्याज दर की गणना के मामले में जटिल व्यावसायिक तर्क | बहुत ऊँचा | दो |
200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है | उच्च | ३ |
सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं | उच्च | ३ |
संभावना:
फ़ीचर | कक्षा | स्केल |
होम लोन की ब्याज दर की गणना के मामले में जटिल व्यावसायिक तर्क | उच्च | ३ |
200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है | उच्च | ३ |
सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं | कम | ४ |
अब इन सभी विशेषताओं को एक साथ रखें:
फ़ीचर | तीव्रता | वरीयता | संभावना |
होम लोन की ब्याज दर की गणना के मामले में जटिल व्यावसायिक तर्क | दो | दो | ३ |
200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है | ३ | ३ | ३ |
सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं | दो | ३ | ४ |
अब जोखिम प्राथमिकता संख्या की गणना करते हैं (RPN = गंभीरता * प्राथमिकता * संभावना)
फ़ीचर | तीव्रता | वरीयता | संभावना | आरपीएन |
होम लोन की ब्याज दर की गणना के मामले में जटिल व्यावसायिक तर्क | दो | दो | ३ | १२ |
200 समवर्ती उपयोगकर्ताओं पर सिस्टम विफल रहता है | ३ | ३ | ३ | २। |
सिस्टम उन दस्तावेजों को संभालने में विफल रहता है जो 6 एमबी से अधिक हैं | दो | ३ | ४ | २४ |
अब कुंजी है: कम RPN है - उच्च जोखिम है।
इसलिए इस विशेष उदाहरण के लिए, फ़ीचर 1 (होम लोन की ब्याज दर की गणना के मामले में कॉम्प्लेक्स व्यावसायिक तर्क) में सबसे अधिक जोखिम है और फीचर 2 (सिस्टम 200 समवर्ती उपयोगकर्ताओं में विफल रहता है) में सबसे कम जोखिम है।
परीक्षण मामलों को प्राप्त करने के लिए इसका उपयोग कैसे करें?
जबसे सुविधा 1 है जोखिम भरी सुविधा परीक्षण के मामले कठोर और अधिक गहराई से होने चाहिए। पूर्ण कार्यक्षमता और सुविधा द्वारा मॉड्यूल को प्रभावित करने के लिए परीक्षण मामलों को लिखें। परीक्षण केस लेखन तकनीक के सभी प्रकारों का उपयोग करें ( समतुल्यता विभाजन और बी.वी.ए. , कारण और प्रभाव ग्राफ , राज्य संक्रमण आरेख ) परीक्षण मामलों को प्राप्त करने के लिए।
परीक्षण के मामले न केवल कार्यात्मक होने चाहिए बल्कि गैर-कार्यात्मक भी होने चाहिए ( भार निरीक्षण , तनाव, और वॉल्यूम परीक्षण, आदि)। मूल रूप से, हमें इस विशेष सुविधा का संपूर्ण परीक्षण करने की आवश्यकता है, इसलिए अपने परीक्षण मामलों को तदनुसार आधार बनाएं। इसके अलावा, इस महत्वपूर्ण विशेषता पर सभी निर्भर मॉड्यूल पर विचार करें।
सुविधा २ है मुख्य जोखिम सुविधा , इसलिए प्रमुख कार्यक्षमता पर अपने परीक्षण मामलों को आधार बनाएं। यह पुष्टि करने के लिए कि उच्च स्तर के परीक्षण के मामले यह सुनिश्चित करने के लिए पर्याप्त हैं कि यह सुविधा पर्याप्त हो।
फ़ीचर 3 एक है आधुनिक जोखिम सुविधा , इसलिए सभी प्रमुख और निर्भर कार्यक्षमता को कवर करने के लिए अपने परीक्षण मामलों को आधार बनाएं। कुछ नकारात्मक परिदृश्यों को भी मान्य करने के लिए कुछ BVA परीक्षण मामलों को लिखें। परीक्षण मामलों की सीमा उच्च जोखिम और कम जोखिम वाले कारक के बीच होनी चाहिए। यदि आवश्यक हो, तो कुछ गैर-कार्यात्मक परीक्षण मामलों को भी शामिल करें।
FMEA और परीक्षण की डिग्री
आरपीएन मूल्य के आधार पर, हम परीक्षण किए जाने की सीमा या डिग्री निर्धारित करते हैं।
आम तौर पर अगर:
- RPN 1-10 के बीच है, हम व्यापक परीक्षण करते हैं (फीचर / मॉड्यूल को कवर करना और बाहर करना)
- RPN 11-30 के बीच है, हम संतुलित परीक्षण (सुविधा / मॉड्यूल की सभी प्रमुख कार्यक्षमता को कवर करते हैं)
- RPN 31-70 के बीच है, हम अवसर परीक्षण करते हैं (फीचर / मॉड्यूल की बुनियादी कार्यक्षमता को कवर करते हुए)
- आरपीएन 70 से अधिक है - कोई परीक्षण या जब समय की अनुमति होती है, केवल विसंगति रिपोर्टिंग।
ये सीमाएँ या संख्याएँ उन लोगों तक सीमित नहीं हैं जिन्हें मैंने ऊपर बताया है। वे परियोजना की प्रकृति के अनुसार भिन्न हो सकते हैं।
संसाधन: डाउनलोड FMEA सॉफ्टवेयर तथा FMEA टेम्पलेट ।
निष्कर्ष
FMEA का उपयोग करके जोखिम विश्लेषण के लिए समय और अनुभव की आवश्यकता होती है। वांछित परिणाम सभी जिम्मेदार टीम के सदस्यों की समान भागीदारी से ही प्राप्त किए जा सकते हैं। यद्यपि यह तकनीक औपचारिक है, इसके लिए मंथन सत्रों की एक श्रृंखला की आवश्यकता होती है और सभी पहचाने गए जोखिमों का दस्तावेजीकरण करना भी उतना ही महत्वपूर्ण है।
चूंकि अधिकांश एप्लिकेशन अनन्य होते हैं, FMEA (यानी प्राथमिकता, गंभीरता, और संभावना) के मापदंडों को मापने का पैमाना भी आवेदन पर निर्भर करता है। यदि उचित रूप से किया जाता है, तो FMEA तकनीक के कई फायदे हैं। इसका उपयोग संभावित जोखिमों की पहचान करने के लिए किया जा सकता है और इस पर आधारित टीम एक प्रभावी शमन रणनीति की योजना बना सकती है।
लेखक के बारे में: शिल्पा चटर्जी रॉय का यह एक अतिथि लेख है। वह विभिन्न डोमेन में पिछले 8.5 वर्षों से सॉफ्टवेयर परीक्षण क्षेत्र में काम कर रही है।
यदि आपने इस तकनीक का उपयोग किया है, तो कृपया नीचे दिए गए अपने अनुभव पर टिप्पणी करने के लिए स्वतंत्र महसूस करें।
अनुशंसित पाठ
- सॉफ्टवेयर परियोजनाओं में जोखिम के प्रकार
- गुणवत्ता गुण क्या हैं?
- अपनी विश्लेषण क्षमताओं और सोच शक्ति का परीक्षण करें - सॉफ्टवेयर परीक्षण अभ्यास (भाग 2)
- परीक्षण में पारस्परिक समझ: एक गुणवत्ता सॉफ्टवेयर देने के लिए एक कुंजी
- सॉफ्टवेयर क्वालिटी एश्योरेंस (SQA) क्या है: ए गाइड फॉर बिगिनर्स
- सतत एकीकरण प्रक्रिया: सॉफ्टवेयर की गुणवत्ता में सुधार और जोखिम को कैसे कम करें
- गुणवत्ता आश्वासन और गुणवत्ता नियंत्रण (क्यूए बनाम क्यूसी) के बीच अंतर
- टॉप 8 बेस्ट लॉग मैनेजमेंट सॉफ्टवेयर | लॉग एनालिसिस टूल रिव्यू 2021