क्या सॉफ़्टवेयर परीक्षण पद्धति त्रुटिपूर्ण डेटा पर निर्भर करती है?


45

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

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

क्या इसको पुष्ट करने या खंडन करने के लिए कोई स्वतंत्र डेटा है?

और अगर सच है (अर्थात यदि केवल देर से खोजे गए बग के लिए इस उच्च लागत का समर्थन करने के लिए कोई डेटा नहीं है), तो यह सॉफ्टवेयर विकास पद्धति को कैसे प्रभावित करता है?


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

8
@ElYusubov यह वास्तव में करता है। लेकिन सामान्य ज्ञान बहुत ही भ्रामक हो सकता है । हमारे दिमाग को आसानी से स्पष्ट तर्क द्वारा धोखा दिया जाता है जब यह वास्तव में दूसरा रास्ता है। इसलिए साक्ष्य-आधारित सॉफ्टवेयर इंजीनियरिंग इतनी महत्वपूर्ण है।
कोनराड रुडोल्फ


2
रिकॉर्ड के लिए (और मेरे उत्तर में उल्लेख किया गया है), इसके बारे में सबसे पहला उल्लेख जो मैंने पाया है वह कोड कम्पलीट से पहले अच्छी तरह से पाया जा सकता है। 1976 में फगन और स्टीफेंसन (स्वतंत्र रूप से) का काम इस का सबसे पहला संदर्भ है जो मुझे मिल सकता है। लगभग 20 साल बाद 1993 तक कोड कम्पलीट का पहला संस्करण प्रकाशित नहीं हुआ था। मुझे उम्मीद है कि 1980 के दशक में बैरी बोहम के काम ने इस विचार की लोकप्रियता में वृद्धि की - बोहेम का काम 1980 के दशक में और यहां तक ​​कि 2000 के दशक के अंत में सॉफ्टवेयर इंजीनियरिंग प्रक्रिया के लिए बहुत प्रभावशाली था।
थॉमस ओवेन्स

1
यह स्वयंसिद्ध है कि सॉफ्टवेयर इंजीनियरिंग के आंकड़ों के बारे में कोई भी बयान गलत है, जिसमें यह भी शामिल है। (आपके द्वारा बाद में पाए जाने वाले कीड़े आम तौर पर अधिक जटिल कीड़े होते हैं। और उन्हें ठीक करना अधिक जटिल होता है "नियंत्रण" द्वारा देर से किए गए फिक्स को फिर से लगाया जाता है।)
डैनियल आर हिक्स

जवाबों:


25

क्या सॉफ़्टवेयर परीक्षण पद्धति त्रुटिपूर्ण डेटा पर निर्भर करती है?

हां, डेन्स्ट्रैबली। चेंज कर्व की चुस्त लागत की जांच से पता चलता है कि केंट बेक के एक्सपी पर काम का हिस्सा (मुझे यकीन नहीं है कि यह उसकी प्रेरणा या उसके औचित्य का हिस्सा था) दोष की लागत को "समतल" करना था, "ज्ञान के आधार पर" घातीय "वक्र जो कोड पूर्ण तालिका के पीछे स्थित है। तो हां, कम से कम एक कार्यप्रणाली पर काम करें - वह जो परीक्षण-पहले विकास को लोकप्रिय बनाने के लिए सबसे अधिक किया गया - कम से कम त्रुटिपूर्ण आंकड़ों के आधार पर।

क्या इसको पुष्ट करने या खंडन करने के लिए कोई स्वतंत्र डेटा है?

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

इसलिए, यह मानते हुए कि हमें अभी भी इन नंबरों को सही ठहराने में समस्या है:

यह सॉफ्टवेयर विकास पद्धति को कैसे प्रभावित करता है?

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

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

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

साक्ष्य-आधारित इंजीनियरिंग के बारे में बहुत बढ़िया मेटा-उत्तर। धन्यवाद।
कोनराड रुडोल्फ

4
धिक्कार है, मुझे बस एहसास हुआ कि यह सीधे घोड़े के मुंह से आ रहा है। हेहे। बहुत बढ़िया।
कोनराड रुडोल्फ

1
मुझे लगता है कि हर कोई "त्रुटिपूर्ण डेटा" के उपयोग की व्याख्या "पूरी तरह से असत्य, विपरीत सच है" के रूप में करता है, लेकिन मुझे लगता है कि आपकी स्थिति बस यह इंगित करने के लिए है कि यह असत्य हो सकता है । क्या ये सही है?
डैनियल बी

3
@ डैनियलबी सही। मुझे सबूत दिखाएं कि यह वास्तव में गलत है और मैं अपना मन बदल सकता हूं; तब तक मैं केवल यही जानता हूं कि यह प्रदर्शन सही नहीं है ।

1
@GrahamLee मैं आपकी बात देखता हूं (बस यह सोचें कि हो सकता है कि फाइटिंग थोड़ा अनावश्यक रूप से आक्रामक हो)। जिज्ञासा से बाहर, मैंने यहां फगन पेपर पाया , और यह कहता है "... पुन: काम करने की अनुमति देता है ... अपने मूल के पास ... 10 से 100 गुना कम महंगा है अगर यह प्रक्रिया के अंतिम छमाही में किया जाता है"। हालाँकि मुझे इस पाठ के पास कोई उद्धरण नहीं दिखता है।
डैनियल बी

8

मेरे हिस्से के लिए, "यह कैसे प्रभाव सॉफ्टवेयर विकास पद्धति को प्रभावित करता है" का जवाब "ज्यादा नहीं" है।

डेवलपर या अंतिम उपयोगकर्ता द्वारा पकड़ा गया, चाहे वह उपयोगकर्ता द्वारा पकड़े जाने के बाद इसे ठीक करने के लिए अधिक पैसा लेता है या नहीं, यह तथ्य यह है कि सिस्टम में बग पाया गया है। यदि डेवलपर द्वारा पकड़ा गया है, तो उम्मीद है कि यह एक त्वरित सुधार है। उपयोगकर्ता द्वारा पकड़े गए बगों के लिए भी यही आशा है।

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

इन अमूर्त लागतों को जल्द ही बग से बचने के लिए पकड़ा जाता है, जो कि टीडीडी-शैली पद्धतियों का घोषित उद्देश्य है। एक जोड़ी में डेवलपर या पार्टनर द्वारा टाइपिंग के दौरान पकड़ा गया बग, एक संकलन समय पर पकड़ा गया, या एक यूनिट / इंटीग्रेशन टेस्टिंग (TDD द्वारा जोड़ी गई परत) द्वारा पकड़ा गया, एक बग है जिसके बारे में उपयोगकर्ता को कभी पता नहीं चलना चाहिए, कि आपका प्रोजेक्ट मैनेजर को कभी भी माफी नहीं मांगनी पड़ती है, और आपको जो कुछ भी सही हो रहा है, उसे गियर को स्विच करने के लिए दोष-फिक्सिंग मोड में उस प्रणाली के एक हिस्से पर स्विच करने से रोकने की ज़रूरत नहीं है जिसे आपने सोचा था कि आप हफ्तों पीछे रह गए हैं। पहले।


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

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

6

मैं इसे इस तथ्य के साथ पेश करने जा रहा हूं कि मैं जो कुछ भी खोज रहा हूं, वह 1970 और 1980 के दशक की शुरुआत से आता है। इस समय के दौरान, अनुक्रमिक प्रक्रिया मॉडल पुनरावृत्ति और / या वृद्धिशील दृष्टिकोण (सर्पिल मॉडल या फुर्तीली विधियों) की तुलना में अधिक सामान्य थे। इस काम का ज्यादातर हिस्सा इन अनुक्रमिक मॉडल पर बनाया गया है। हालाँकि, मुझे नहीं लगता है कि यह रिश्ते को नष्ट कर देता है, लेकिन पुनरावृत्तियों / वृद्धिशील दृष्टिकोणों में से एक लाभ सुविधाओं को जारी करना है (एक आवेदन का एक पूरा ऊर्ध्वाधर टुकड़ा) जल्दी और सही समस्याओं में यह निर्भरता है कि प्रत्येक चरण में इंजेक्शन और जटिलता है। ऊंचा है।


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

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

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

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

सॉफ्टवेयर इंजीनियरिंग इकोनॉमिक्स में बोहेम पर आधारित, कोड कम्प्लीट में टेबल बल्कि फूला हुआ है (श्रेणियों का कम अंत अक्सर बहुत अधिक होता है)। चरण के भीतर किसी भी परिवर्तन करने की लागत वास्तव में है 1. सॉफ्टवेयर इंजीनियरिंग अर्थशास्त्र में चित्रा 4-2 से बाहर निकालना, एक आवश्यकता परिवर्तन वास्तुकला में 1.5-2.5 गुना, कोडिंग में 2.5-10, परीक्षण में 4-20 और 4-4 होना चाहिए। रखरखाव में 100। राशि परियोजना के आकार और जटिलता के साथ-साथ उपयोग की जाने वाली प्रक्रिया की औपचारिकता पर निर्भर करती है।


बैरी बोहम के अपेंडिक्स ई में और रिचर्ड टर्नर की संतुलन क्षमता और अनुशासन में परिवर्तन की लागत के बारे में अनुभवजन्य निष्कर्षों पर एक छोटा सा खंड शामिल है।

प्रारंभिक पैराग्राफ केंट बेक के चरम प्रोग्रामिंग समझाया, बेक के हवाले से उद्धृत करते हैं। इसमें कहा गया है कि यदि समय के साथ परिवर्तनों की लागत धीरे-धीरे बढ़ी, तो निर्णय यथासंभव देर से किए जाएंगे और केवल उसी चीज की आवश्यकता होगी जो कार्यान्वित की जाएगी। यह "सपाट वक्र" के रूप में जाना जाता है और यह वही है जो चरम प्रोग्रामिंग करता है। हालाँकि, पिछले साहित्य में पाया गया कि "खड़ी वक्र", छोटी प्रणालियों (<5 KSLOC) में 5: 1 का परिवर्तन है और बड़े सिस्टम में 100: 1 का परिवर्तन है।

यह खंड मैरीलैंड के सेंटर फॉर एम्पैरिकली बेस्ड सॉफ्टवेयर इंजीनियरिंग (नेशनल साइंस फाउंडेशन द्वारा प्रायोजित) का हवाला देता है। उन्होंने उपलब्ध साहित्य की खोज की और पाया कि परिणाम 100: 1 अनुपात की पुष्टि करने के लिए गए, कुछ परिणामों के साथ 70: 1 से 125: 1 की सीमा का संकेत मिलता है। दुर्भाग्य से, ये आम तौर पर "बड़े डिज़ाइन अप फ्रंट" प्रोजेक्ट थे और क्रमबद्ध तरीके से प्रबंधित होते थे।

चरम प्रोग्रामिंग का उपयोग करके "छोटे वाणिज्यिक जावा प्रोजेक्ट्स" के नमूने हैं। प्रत्येक स्टोरी के लिए, एरर फिक्सिंग, नए डिज़ाइन और रीफैक्टरिंग में प्रयास की मात्रा को ट्रैक किया गया था। डेटा दिखाता है कि जैसे-जैसे सिस्टम विकसित होता है (अधिक उपयोगकर्ता कहानियां लागू की जाती हैं), औसत प्रयास एक गैर-तुच्छ दर में वृद्धि करता है। रिफैक्टरिंग में प्रयास लगभग 5% बढ़ जाता है और प्रयास फिक्सिंग के प्रयासों में लगभग 4% की वृद्धि होती है।

मैं जो सीख रहा हूं, वह यह है कि सिस्टम जटिलता जरूरत के प्रयास में एक महान भूमिका निभाता है। सिस्टम के माध्यम से ऊर्ध्वाधर स्लाइस का निर्माण करके, आप ढेर में जोड़ने के बजाय धीरे-धीरे जटिलता को जोड़कर वक्र की दर को धीमा कर देते हैं। एक अत्यंत जटिल वास्तुकला के बाद आवश्यकताओं की जटिलता के द्रव्यमान से निपटने के बजाय, एक अत्यंत जटिल कार्यान्वयन के बाद, और इसी तरह, आप बहुत सरलता से शुरू करते हैं और जोड़ते हैं।

इसे ठीक करने की लागत पर क्या प्रभाव पड़ता है? अंत में, शायद ज्यादा नहीं। हालांकि, इसमें जटिलता (तकनीकी ऋण के प्रबंधन के माध्यम से) पर अधिक नियंत्रण के लिए अनुमति देने के फायदे हैं। इसके अलावा, अक्सर सुपुर्दगी से जुड़े अक्सर का मतलब है कि परियोजना जल्द ही समाप्त हो सकती है - "सिस्टम" को वितरित करने के बजाय, टुकड़ों को तब तक वितरित किया जाता है जब तक कि व्यवसाय की आवश्यकताएं पूरी नहीं होती हैं या बहुत तेजी से बदल गई हैं कि एक नई प्रणाली (और इसलिए एक नई परियोजना) जरूरत है।


सॉफ्टवेयर क्वालिटी इंजीनियरिंग में स्टीफन कान के मेट्रिक्स एंड मॉडल्स में चरण 6 दोष की लागत प्रभावशीलता के बारे में अध्याय 6 में एक खंड है।

उन्होंने फगन के 1976 के पेपर (सॉफ्टवेयर इंजीनियरिंग अर्थशास्त्र में भी उद्धृत) का हवाला देते हुए कहा कि उच्च स्तर के डिजाइन (सिस्टम आर्किटेक्चर), निम्न स्तर के डिजाइन (विस्तृत डिजाइन) में किया गया, और कार्यान्वयन 10 से 100 गुना कम महंगा हो सकता है। घटक और सिस्टम स्तर परीक्षण के दौरान किए गए कार्य की तुलना में।

वह 1982 और 1984 के दो प्रकाशनों का भी हवाला देते हैं, जो फ्रीडमैन और वेनबर्ग द्वारा बड़े सिस्टम पर चर्चा करते हैं। पहला "हैंडबुक ऑफ़ वॉकथ्रूज़, इंस्पेक्शन एंड टेक्निकल रिव्यू" और दूसरा "रिव्यू, वॉकथ्रूज़ और इंस्पिरेशन" है। विकास चक्र में शुरुआती समीक्षाओं के आवेदन से 10. के कारक द्वारा परीक्षण चरणों तक पहुंचने वाली त्रुटियों की संख्या को कम किया जा सकता है। दोषों की संख्या में कमी से परीक्षण लागत 50% से 80% तक कम हो जाती है। मुझे अध्ययनों को अधिक विस्तार से पढ़ना होगा, लेकिन ऐसा प्रतीत होता है कि लागत में दोषों को ढूंढना और उन्हें ठीक करना भी शामिल है।

1983 में रेमस द्वारा "इंस्पेक्ट्स / रिव्यू के व्यू में इंटीग्रेटेड सॉफ्टवेयर वैलिडेशन" के एक अध्ययन में कैलिफोर्निया में आईबीएम की सांता टेरेसा प्रयोगशाला के डेटा का उपयोग करके विभिन्न चरणों में दोषों को दूर करने, विशेष रूप से डिजाइन / कोड निरीक्षण, परीक्षण और रखरखाव का अध्ययन किया गया। उद्धृत परिणाम 1:20:82 की लागत अनुपात का संकेत देते हैं। यही है, डिजाइन या कोड निरीक्षण में पाया गया एक दोष 1. का लागत-में-परिवर्तन है। यदि एक ही दोष परीक्षण में बच जाता है, तो यह 20 गुना अधिक खर्च होगा। यदि यह उपयोगकर्ता के लिए सभी तरह से बच जाता है, तो यह 82 तक की लागत-से-सही कई हो जाएगा। कन, आईबीएम के रोचेस्टर, मिनियासोटा सुविधा के नमूना डेटा का उपयोग करते हुए, एएस / 400 परियोजना के लिए दोष हटाने की लागत समान होने का पता चला 1:13:92 पर। हालांकि, वह बताते हैं कि लागत में वृद्धि दोष खोजने के लिए बढ़ी हुई कठिनाई के कारण हो सकती है।

गिल्ब के 1993 ( "सॉफ्टवेयर निरीक्षण" ) और 1999 ("सॉफ्टवेयर इंजीनियरिंग विनिर्देश और गुणवत्ता नियंत्रण प्रक्रियाओं का अनुकूलन") सॉफ्टवेयर निरीक्षण पर प्रकाशन अन्य अध्ययनों को पुष्टि करने के लिए उल्लेखित हैं।


कांस्ट्रेक्स के पृष्ठ पर दोषपूर्ण लागत वृद्धि पर अतिरिक्त जानकारी मिल सकती है , जो दोष-मरम्मत लागत में वृद्धि पर कई संदर्भ प्रदान करती है। यह ध्यान दिया जाना चाहिए कि स्टीव मैककोनेल, कोड कम्प्लीट के लेखक, कॉन्स्ट्रेक्स के लिए स्थापित और काम करते हैं।


मैं हाल ही में की बात सुनी एक टॉक रियल सॉफ्टवेयर इंजीनियरिंग , द्वारा दिए गए ग्लेन Vanderburg 2010 वह मैदान पर एक ही बात को देखते हुए में लोन स्टार रूबी सम्मेलन में स्कॉटिश रूबी सम्मेलन और Erubycon 2011 में, 2012 में QCon सैन फ्रांसिस्को , और ओ रेली सॉफ्टवेयर वास्तुकला सम्मेलन 2015 में । मैंने केवल लोन स्टार रूबी सम्मेलन की बात सुनी है, लेकिन समय के साथ बात विकसित हुई है क्योंकि उनके विचारों को परिष्कृत किया गया था।

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

मुझे लगता है कि यह शायद वास्तविकता के करीब है। एक झरने की परियोजना में, लागत बढ़ जाती है क्योंकि कलाकृतियों की मात्रा जो एक अपस्ट्रीम समस्या के कारण सही होने की आवश्यकता होती है। सॉफ्टवेयर में जटिलता की वृद्धि के कारण, पुनरावृत्ति और वृद्धिशील परियोजनाओं में लागत बढ़ जाती है।


@AndresF। इन उद्धरणों को ट्रैक करने में मुझे जो समस्याएँ मिलीं, उनमें से एक यह है कि बॉसविट ने आपको जिस पुस्तक से जोड़ा है, उसमें "सुई इन ए हिस्टैक" समस्या है। एक पुस्तक का हवाला देना बहुत बड़ा विरोधाभास है - भले ही वह अभी भी प्रिंट में हो, जब आप उद्धरण पढ़ने के लिए जाते हैं, तो आपको कुछ सौ पेज पढ़ने के लिए मिलेंगे, जो कि लेखक की दावेदारी का हवाला देने वाले छोटे सोने की डली की तलाश में हैं।

3

इसका सिर्फ सरल तर्क है।

कल्पना में त्रुटि का पता चला।

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

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

उत्पादन सॉफ्टवेयर में त्रुटि (खोई हुई बिक्री, ऑर्डर देने, ग्राहकों को हैक करने आदि) के कारण व्यवसाय को शामिल किए बिना यह सब शामिल हो सकता है।

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


2
यह केवल एक मामले को कवर करता है: कल्पना में त्रुटि का पता चला, यानी एक त्रुटि जो बहुत शुरुआत में पेश की गई है। लेकिन विकास के सभी चरणों में त्रुटियों को पेश किया जा सकता है (पोस्ट-तैनाती बग फिक्सिंग सहित) और उन त्रुटियों को ठीक करना काफी आसान होगा क्योंकि वे संभवतः सिस्टम के एक छोटे हिस्से को प्रभावित करेंगे।
कोनराड रुडोल्फ

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

2
मुझे अभी भी यकीन नहीं है कि यह दिखाता है कि देर से खोजे जाने पर बग्स को ठीक करना हमेशा महंगा होगा। मैं यह दावा करूंगा कि एक बग अपने परिचय के बाद गुजरने वाले समय के साथ तय करने के लिए अधिक महंगा हो जाता है । यानी बग को देर से पेश किया गया, जल्द ही खोजा गया और तय किया गया बग बहुत सस्ता है, जिसे बहुत पहले पेश किया गया था और जल्दी खोजा गया था (लेकिन पहले मामले की तुलना में अधिक देरी के साथ)। कम से कम मैं सोच सकता था कि यह कैसे काम करता है।
कोनराड रुडोल्फ

@KonradRudolph क्या आप विस्तृत कर सकते हैं? यह पोस्ट मेरी समझ के साथ बहुत सुंदर है, और मैं यह नहीं देख रहा हूं कि समय क्यों मायने रखेगा लेकिन चरण नहीं होता है। मेरे लिए, एक परियोजना में समय का माप आपका वर्तमान चरण है (और कभी-कभी सभी चरणों के माध्यम से जाने के लिए आपका समय-समय पर पुनरावृत्ति)। मुझे विस्तृत डिज़ाइन और डे 300 के दिन 3 में किए गए काम के बीच अंतर नहीं दिखता है - विस्तृत डिज़ाइन कार्य उत्पाद का उपयोग किसी अन्य कार्य उत्पाद को बनाने के लिए नहीं किया गया है, इसलिए विस्तृत डिज़ाइन में इंजेक्ट किया गया दोष केवल एक ही स्थान पर मौजूद है और केवल वहां बदलाव की जरूरत है। मैं यह नहीं देखता कि दिन कैसे बीतते हैं।
थॉमस ओवेन्स

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

2

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

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

एक त्वरित खोज से कुछ प्रासंगिक कागजात (पूर्ण पत्र पढ़ें, अधिक शोध करें, और अपनी राय बनाएं):

सॉफ्टवेयर गुणवत्ता लागत अनुसंधान (2011) का एक व्यवस्थित साहित्य समीक्षा

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

सॉफ्टवेयर गुणवत्ता की लागत का मूल्यांकन (1998)

"अंत में, हमने देखा है कि सॉफ़्टवेयर अनुरूपता और गैर-अनुरूपता लागतों की निगरानी करना महत्वपूर्ण है ताकि सॉफ्टवेयर गुणवत्ता की कुल लागत को कम करने के लिए अनुरूप नीतियों को समायोजित किया जा सके।"

सॉफ्टवेयर दोषों की लागत व्यवहार (2004)

सार ... "वर्तमान शोध हमारे ज्ञान को उस तरीके से अपडेट करने का प्रयास करता है जिसमें दोष और उन्हें सही करने का खर्च (या वैकल्पिक रूप से, उन्हें बिना सोचे-समझे छोड़ देना) सॉफ़्टवेयर की अंतिम लागत को प्रभावित करता है" ... "अयोग्य दोष अधिक महंगा हो जाता है। प्रत्येक चरण के साथ जिसमें वे अनसुलझे हैं "

टेस्ट कवरेज और पोस्ट-वेरीफिकेशन दोष: एक मल्टीपल केस स्टडी (2009)

"हम यह भी पाते हैं कि परीक्षण कवरेज के साथ परीक्षण का प्रयास तेजी से बढ़ता है, लेकिन क्षेत्र की समस्याओं में कमी परीक्षण कवरेज के साथ रैखिक रूप से बढ़ जाती है। इससे पता चलता है कि अधिकांश परियोजनाओं के लिए कवरेज का इष्टतम स्तर 100% से कम होने की संभावना है।"

सॉफ्टवेयर टेस्ट प्रक्रिया और व्यावसायिक मूल्य के बीच अंतर को पाटना: एक केस स्टडी (2009)


0

मैं आपके प्रश्न के पहले भाग का उत्तर नहीं दे सकता, क्योंकि मैंने अभी जाँच नहीं की है। लेकिन मैं आपके दूसरे प्रश्न का उत्तर तैयार कर सकता हूं, और संभवत: पहले के संभावित उत्तर पर संकेत कर सकता हूं।

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

कोड पर एक दूसरे के लिए ध्यान केंद्रित करना, इस धारणा के तहत कि कोड आमतौर पर डेवलपर्स द्वारा उनके कोड की आंतरिक जटिलताओं से निपटने में सक्षम और बनाए रखा जाता है (जो पूरी तरह से सच नहीं हो सकता है और अपनी खुद की बहस के लायक हो सकता है), मैं आपको सुझाव दूंगा कि रखरखाव में cricital महत्व, और इस प्रकार कीड़े को ठीक करने में, अनुचर कोड को समझने की क्षमता है ।

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

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

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

अपवाद हैं। मुझे यकीन है कि Google तारकीय डेवलपर्स द्वारा कुछ ठोस प्रथाओं के बिना अपनी गति से काम नहीं कर रहा है। और अन्य समान स्थिति में होने की संभावना है। लेकिन सॉफ्टवेयर के बहुमत के लिए, मैं हैरान नहीं किया जाएगा अगर डेटा किया तथ्य की पुष्टि में में दावा संहिता पूरा


मैं नकारात्मक रेटिंग के साथ भी अपने जवाब के साथ खड़ा हूं। मैंने हाल ही में एक उम्मीदवार का साक्षात्कार लिया, जो शीर्ष बैंकों में से एक का ऑनलाइन बैंकिंग टूल रखता है। कैज़ुअल चैट के दौरान, उन्होंने भारी कॉपी-पेस्ट पुन: उपयोग और अन्यथा घटिया संरचना के कारण, इसका उपयोग नहीं करने का सुझाव दिया। पिछली नौकरी में, मैं लेहमैन, एमएस, यूबीएस जैसे बैंकों के लिए विश्लेषण उपकरण लिखने वाली एक कंपनी में एक डेवलपर था, और हमें डोमेन विशेषज्ञों के रूप में कार्य करना था, जो कि सबसे विरल प्रलेखन से दूसरी शाखा में डालने के लिए अगली बात का पता लगा रहा था। भले ही विशिष्ट प्रथाओं से असहमति में, समग्र संदेश पुनः: उद्योग सत्य है।
महाई दानिला

-1

एक और जवाब! इस बार शीर्षक प्रश्न को संबोधित करने के लिए "क्या सॉफ्टवेयर नैतिकतावादी त्रुटिपूर्ण आंकड़ों पर भरोसा करते हैं"।

असली जवाब "कोई डेटा नहीं है" है। जैसे कि सॉफ्टवेयर परियोजनाओं पर डेटा का कोई बड़ा विश्वसनीय निकाय नहीं है, इसमें दोष, बाजार में सफलता का समय आदि शामिल हैं।

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

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

सॉफ्टवेयर परियोजनाओं की लागत और सफलता पर संख्या को प्रकाशित करने वाले एकमात्र संगठन
सरकारी विभाग हैं, और, केवल इसलिए कि उन्हें करना है, और, हां ये संख्या कोई भी बात नहीं है कि वे आंकड़ों की मालिश कितना शर्मनाक है।

तो निष्कर्ष में सभी सॉफ्टवेयर अध्ययन आवश्यक रूप से व्यक्तिपरक हैं क्योंकि कोई वास्तविक डेटा नहीं है, जिस पर एक उद्देश्य निष्कर्ष निकाला जाए।


1
नहीं, मैं इसे नहीं खरीदता। सबसे पहले, वहाँ है डेटा हालांकि आप हो सकता है सही है कि यह त्रुटिपूर्ण है। लेकिन इसके लिए प्रत्येक डेटा सेट की एक व्यक्तिगत आलोचना की आवश्यकता होती है, न कि सामान्य बर्खास्तगी की। और मुझे इस विवाद पर गहरा संदेह है कि कभी भी डेटा नहीं होगा, और ऐसे कारणों के रूप में "यह बहुत व्यक्तिपरक है"। यह अनिवार्य रूप से कल्पना की कमी से एक तर्क है । मैं इस बात का ढोंग नहीं करता कि यहाँ विश्वसनीय आंकड़े जुटाना आसान है, लेकिन मैं मानता हूँ कि यह पूरी तरह से संभव है। अन्य क्षेत्रों में, जिस तरह से अधिक जटिल प्रणालियों का सफलतापूर्वक विश्लेषण किया जाता है।
कोनराड रुडोल्फ

@ कोनराड - "बेसिक काउंट" की तरह कुछ बेसिक और सिंपल लें, कुछ शॉप्स यूनिट टेस्ट में फेल हो जाते हैं, कुछ शॉप्स यूएटी तक ट्रैकिंग दोष शुरू नहीं करती हैं, कुछ शॉप्स कोड में ही डिफेक्ट्स ट्रैक करती हैं, कुछ शॉप्स में डॉक्यूमेंटेशन, कॉन्फ़िगरेशन और उनके दोष ट्रैकिंग प्रक्रिया में लिपियों की तैनाती। क्या गलत पृष्ठभूमि का रंग दोष के रूप में गिना जाता है? कुछ परियोजनाएं इसे एक दोष के रूप में ट्रैक करेंगी जबकि अन्य इसे अनदेखा करेंगे।
जेम्स एंडरसन

वे सभी पारलौकिक हैं - अर्थात हल करने योग्य - समस्याएँ। वे मौलिक बाधाओं को नहीं रखते हैं जो संभव है, वे बस कठिनाइयों को जोड़ते हैं जिन्हें हल करने की आवश्यकता होती है।
कोनराड रुडोल्फ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.