कॉग्नोस आणि आपल्या बीआयची चाचणी न करण्याची किंमत

ऑगस्ट 28, 2019 अद्यतनित केले

सॉफ्टवेअर विकसित झाल्यापासून सॉफ्टवेअर डेव्हलपमेंटचा एक भाग म्हणून चाचणी मोठ्या प्रमाणावर स्वीकारली गेली आहे. आयबीएम कॉग्नोस सारख्या बीआय सॉफ्टवेअरमध्ये विकासाचा एकात्मिक भाग म्हणून बिझनेस इंटेलिजन्स (बीआय) मात्र चाचणी घेण्यास धीमी आहे. BI चाचणी पद्धती आणि त्याचे परिणाम स्विकारण्यास धीमे का आहे याचा शोध घेऊया नाही चाचणी

संस्था बीआयची चाचणी का घेत नाहीत ...

• वेळेचा निर्बंध. BI प्रकल्पांवर वेगवान वितरणासाठी सतत दबाव असतो. काही संस्थांना कदाचित लक्षात येत नाही की वेळ कमी करण्याचा सर्वात सोपा टप्पा म्हणजे चाचणी.
• बजेटची मर्यादा. विचार हा आहे की चाचणी करणे खूप महाग आहे आणि चाचणी संघाला समर्पित करू शकत नाही.
• जलद चांगले आहे. हा अपरिहार्यपणे "चपळ" दृष्टीकोन नाही आणि कदाचित आपल्याला चुकीच्या ठिकाणी लवकर पोहोचवेल.

• "फक्त पहिल्यांदा बरोबर करा" मानसिकता. हा भोळा दृष्टिकोन आग्रह धरतो की गुणवत्ता नियंत्रणाच्या उपस्थितीने चाचणीची गरज कमी केली पाहिजे.
• मालकीचा अभाव. हे मागील बुलेटसारखेच आहे. विचार असा आहे की "आमचे वापरकर्ते त्याची चाचणी करतील." या दृष्टिकोनामुळे दुखी वापरकर्ते आणि बरीच समर्थन तिकिटे होऊ शकतात.
• साधनांचा अभाव. त्यांच्याकडे चाचणीसाठी योग्य तंत्रज्ञान नाही असा गैरसमज.
• चाचण्यांच्या आकलनाचा अभाव. उदाहरणार्थ,
  • चाचणीने डेटाची अचूकता आणि वैधता, डेटा सुसंगतता, डेटाची वेळ, वितरण कार्यक्षमता आणि वितरण यंत्रणेचा वापर सुलभतेचे मूल्यांकन केले पाहिजे.
  • बीआय प्रोजेक्ट दरम्यान चाचणीमध्ये रिग्रेशन टेस्टिंग, युनिट टेस्टिंग, स्मोक टेस्टिंग, इंटिग्रेशन टेस्टिंग, यूजर स्वीकृती टेस्टिंग, तदर्थ चाचणी, स्ट्रेस/स्केलेबिलिटी टेस्टिंग, सिस्टम परफॉर्मन्स टेस्टिंग यांचा समावेश असू शकतो.

बीआय चाचणी न करण्याच्या किंमती काय आहेत?

• अकार्यक्षम डिझाईन्स. चाचणीकडे दुर्लक्ष केल्यास खराब वास्तुकला शोधला जाऊ शकत नाही. डिझाइन मुद्दे वापरण्यायोग्यता, कामगिरी, पुन्हा वापर, तसेच, देखभाल आणि देखरेखीसाठी योगदान देऊ शकतात.
• डेटा अखंडता समस्या. डेटा भ्रष्टाचार किंवा डेटा वंशाच्या आव्हानांमुळे संख्यांवर विश्वास कमी होऊ शकतो.
• डेटा प्रमाणीकरण समस्या. खराब डेटावर घेतलेले निर्णय व्यवसायासाठी विनाशकारी असू शकतात. चुकीच्या माहितीवर आधारित मेट्रिक्सद्वारे व्यवस्थापित करण्याचा प्रयत्न करण्यापेक्षा वाईट काहीही नाही.

• वापरकर्ता दत्तक कमी. संख्या योग्य नसल्यास, किंवा अनुप्रयोग वापरकर्ता अनुकूल नसल्यास, आपला वापरकर्ता समुदाय फक्त आपले चमकदार नवीन एंटरप्राइझ BI सॉफ्टवेअर वापरणार नाही.
• मानकीकरणाच्या अभावामुळे वाढलेला खर्च.
• बीआय विकास जीवनचक्राच्या नंतरच्या टप्प्यात दोष दुरुस्त करण्यासाठी वाढलेला खर्च. आवश्यकतांच्या टप्प्याच्या पलीकडे सापडलेल्या कोणत्याही समस्यांची किंमत आधी शोधल्यापेक्षा जास्त खर्च येईल.

आता आम्ही हे स्पष्ट केले आहे की संस्था चाचणी का करत नाहीत आणि जेव्हा आपण बीआयची चाचणी घेत नाही तेव्हा होणारे तोटे, सॉफ्टवेअर डेव्हलपमेंटमधील चाचणीवरील काही अभ्यास पाहू.

अभ्यास दाखवा तुमच्या BI प्लॅटफॉर्मची चाचणी करणे पैसे वाचवते!

139 उत्तर अमेरिकन कंपन्यांचा एक अभ्यास 250 ते 10,000 कर्मचाऱ्यांच्या आकारात, $ 5.2M ते $ 22M च्या वार्षिक डीबगिंग खर्चाची नोंद केली. ही किंमत श्रेणी त्या संस्थांना प्रतिबिंबित करते करू नका त्या ठिकाणी स्वयंचलित युनिट चाचणी आहे. स्वतंत्रपणे, आयबीएम आणि मायक्रोसॉफ्टच्या संशोधनात असे आढळले सह ठिकाणी स्वयंचलित युनिट चाचणी, दोषांची संख्या 62% आणि 91% दरम्यान कमी केली जाऊ शकते. याचा अर्थ असा की डिबगिंगवर खर्च केलेले डॉलर्स $ 5M - $ 22M रेंज पासून $ 0.5M ते $ 8.4M रेंज पर्यंत कमी केले जाऊ शकतात. ही मोठी बचत आहे!

चुका लवकर सुधारण्यासाठी खर्च.

यशस्वी सॉफ्टवेअर डेव्हलपमेंट डावपेचांवर एक पेपर हे दर्शविते की बहुतेक त्रुटी विकास चक्राच्या सुरुवातीला केल्या जातात आणि आपण शोधण्यासाठी आणि दुरुस्त करण्यासाठी जितका जास्त वेळ प्रतीक्षा कराल तितकीच ती दुरुस्त करण्यासाठी जास्त खर्च येईल. म्हणून, जितक्या लवकर त्रुटी शोधल्या आणि दुरुस्त केल्या, तितके चांगले, असा स्पष्ट निष्कर्ष काढण्यासाठी रॉकेट शास्त्रज्ञाची गरज नाही. रॉकेट विज्ञानाबद्दल बोलताना, असे घडते की नासाने फक्त त्यावर एक पेपर प्रकाशित केला - "प्रोजेक्ट लाइफ सायकलद्वारे एरर कॉस्ट एस्केलेशन."

विकास जीवन-चक्र जसजसे पुढे जाते तसतसे त्रुटी दूर करण्यासाठी खर्च वाढतो हे अंतर्ज्ञानी आहे. शोधलेल्या त्रुटी दूर करण्याच्या सापेक्ष खर्चाची प्रगती किती वेगाने होते हे निर्धारित करण्यासाठी नासाचा अभ्यास करण्यात आला. या अभ्यासामध्ये सापेक्ष खर्च ठरवण्यासाठी तीन पध्दती वापरल्या गेल्या: तळ-वर खर्च पद्धत, एकूण खर्च खंडित करण्याची पद्धत आणि टॉप-डाउन काल्पनिक प्रकल्प पद्धत. या पेपरमध्ये वर्णन केलेले दृष्टिकोन आणि परिणाम एखाद्या हार्डवेअर/सॉफ्टवेअर सिस्टीमचा विकास गृहित धरतात ज्यात प्रकल्पाची वैशिष्ट्ये मोठ्या, जटिल अंतराळयान, लष्करी विमान किंवा लहान संप्रेषण उपग्रहाच्या विकासात वापरल्या जातात. परिणाम ज्या प्रमाणात खर्च वाढतो ते दर्शवतात, कारण प्रोजेक्टच्या जीवनचक्रात नंतर आणि नंतरच्या टप्प्यांवर त्रुटी शोधल्या जातात आणि निश्चित केल्या जातात. हा अभ्यास इतर संशोधनांचा प्रतिनिधी आहे जो केला गेला आहे.

वरील चार्टवरून, टीआरडब्ल्यू, आयबीएम, जीटीई, बेल लॅब्स, टीडीसी आणि इतरांचे संशोधन विविध विकास टप्प्यांत त्रुटी दूर करण्याची किंमत दर्शवते:

• आवश्यकता टप्प्यात सापडलेल्या त्रुटीचे निराकरण करण्याची किंमत म्हणून परिभाषित केली आहे 1 युनिट
• डिझाईन टप्प्यात आढळल्यास ती त्रुटी दूर करण्याची किंमत आहे दुप्पट की
• कोड आणि डीबग टप्प्यावर, त्रुटी दूर करण्याची किंमत आहे 3 युनिट
• युनिट चाचणी आणि समाकलित टप्प्यावर, त्रुटी दूर करण्यासाठी खर्च होतो 5
• सिस्टीम चाचणी टप्प्यात, त्रुटी दूर करण्यासाठी खर्च 20 वर जातो
• आणि एकदा प्रणाली ऑपरेशन टप्प्यात आली, त्रुटी सुधारण्यासाठी सापेक्ष खर्च 98 पर्यंत वाढला आहे, जर आवश्यकता टप्प्यात आढळल्यास त्रुटी सुधारण्याच्या किंमतीच्या 100 पट!

मुख्य गोष्ट अशी आहे की दोष लवकर पकडले गेले नाहीत तर ते दुरुस्त करणे अधिक महाग आहे.

निष्कर्ष

महत्त्वपूर्ण संशोधन केले गेले आहे जे सॉफ्टवेअर डेव्हलपमेंटमध्ये लवकर आणि सतत चाचणीचे मूल्य दर्शवते. आम्ही, BI समुदायात, सॉफ्टवेअर डेव्हलपमेंटमध्ये आमच्या मित्रांकडून शिकू शकतो. जरी सॉफ्टवेअर डेव्हलपमेंटशी संबंधित बहुतेक औपचारिक संशोधन केले गेले असले तरी, बीआय डेव्हलपमेंटबद्दल समान निष्कर्ष काढले जाऊ शकतात. चाचणीचे मूल्य निर्विवाद आहे, परंतु बर्‍याच संस्था त्यांच्या बीआय पर्यावरणाच्या औपचारिक चाचणीचा लाभ घेण्यासाठी आणि त्यांच्या बीआय विकास प्रक्रियेत चाचणी समाकलित करण्यासाठी मंद आहेत. चा खर्च नाही चाचणी खरी आहे. संबंधित धोके नाही चाचणी खरी आहे.

काही स्वयंचलित कॉग्नोस चाचणी कृतीत पाहू इच्छिता? आमच्या प्लेलिस्ट वर व्हिडिओ पहा येथे क्लिक करा!