Economics essay No FPGA board result in this paper

अपरीक्षित इंटरफ़ेस की कीमत

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

David Charlot, Open Interface Engineering

यह अंग्रेज़ी संस्करण का अनुवाद है। किसी भी अंतर की स्थिति में अंग्रेज़ी संस्करण मान्य होगा। मूल अंग्रेज़ी.

Research studies, not journal finals. Notation is defined in the paper. Analytical energy estimates are not board power. Interactive figures live under /living/. Shared terms: glossary.

Cite this

David Charlot, Open Interface Engineering. अपरीक्षित इंटरफ़ेस की कीमत. Open Interface Engineering. Web: https://research.openie.dev/papers/interface-economics/. PDF: https://research.openie.dev/pdfs/interface-economics.pdf.

संस्करण 1.0, 11 अक्टूबर 2026। LaTeX PDF: /pdfs/latex/interface-economics.pdf (स्रोत)।

सारांश

यह निबंध उन विफलताओं की प्रकाशित लागतों को एकत्र करता है जो किसी प्रणाली के हिस्सों के बीच हस्तांतरणों पर होती हैं, और हर आँकड़े पर यह लेबल लगाता है कि वह कैसे तैयार किया गया। यह उन्हें जोड़कर एक कुल योग नहीं बनाता।

सरल शब्दों में

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

0. परिभाषाएँ और दायरा

इंटरफ़ेस एक हस्तांतरण है जिसके पार एक पक्ष का आउटपुट दूसरे पक्ष का इनपुट बन जाता है: उन लोगों से जो बताते हैं कि किसी प्रणाली को क्या करना चाहिए (सिद्धांतकार), उन तक जो उसे बनाते हैं (निर्माता), उन तक जो उसे चलाते हैं (उपयोगकर्ता), या किसी सॉफ़्टवेयर और हार्डवेयर स्टैक के दो स्तरों के बीच। इंटरफ़ेस धारणा उन मानों पर एक शर्त है जो हस्तांतरण को पार करते हैं और जिस पर प्राप्त करने वाला पक्ष अपनी शुद्धता के लिए निर्भर करता है, जैसे कोई इकाई, कोई परास, कोई टाइप, कोई संस्करण या कोई परिचालन आवरण। कोई धारणा अपरीक्षित तब है जब उस पर निर्भर तो रहा जाता है, पर उसे न लिखा गया है न जाँचा गया है। इंजीनियरिंग का एक लंबा साहित्य, वास्तुशिल्पीय बेमेल पर Garlan, Allen और Ockerbloom से लेकर दुर्घटनाओं को अंतःक्रिया विफलताओं के रूप में देखने वाले Leveson तक, प्रणालियों की कई विफलताओं को ऐसी ही धारणाओं में स्थित करता है [19, 20]। यह निबंध पूछता है कि इन विफलताओं की लागत क्या है, और उत्तर केवल उन आँकड़ों से देता है जो कोई प्राथमिक स्रोत बताता है। हर आँकड़े पर उसके प्रकार का लेबल है। लेखांकित लागत वह है जो कोई एजेंसी या फ़र्म बताती है कि उसने वास्तव में खर्च की या गँवाई। मॉडल अनुमान वह आँकड़ा है जो सर्वेक्षणों, साक्षात्कारों या द्वितीयक आँकड़ों से किसी घोषित पद्धति द्वारा तैयार किया जाता है। प्रक्षेपण भविष्य के बारे में एक कथन है। तीनों प्रकारों को आपस में जोड़ा नहीं जाता।

एकल इंटरफ़ेस विफलताओं की लेखांकित लागतें बड़ी और विशिष्ट हैं: Mars Surveyor 1998 परियोजना, जिसमें Mars Climate Orbiter शामिल था, की लागत $327.6 मिलियन थी [1], और ESA ने पहले Ariane 5 पर खोए Cluster मिशन को पुनः प्राप्त करने के लिए 214 मिलियन ECU स्वीकृत किए [4]। मॉडल अनुमान और बड़े तथा व्यापक हैं: NIST ने संयुक्त राज्य अमेरिका में अपर्याप्त सॉफ़्टवेयर परीक्षण अवसंरचना की वार्षिक लागत $59.5 बिलियन आँकी [6], और अमेरिकी पूंजीगत सुविधा उद्योग में अपर्याप्त अंतरसंचालनीयता की लागत $15.8 बिलियन प्रति वर्ष [7]। CISQ ने 2022 में संयुक्त राज्य अमेरिका में खराब सॉफ़्टवेयर गुणवत्ता की लागत कम से कम $2.41 ट्रिलियन और संचित तकनीकी ऋण लगभग $1.52 ट्रिलियन आँका [8]। इनमें से कोई भी अकेले इंटरफ़ेस विफलता को नहीं मापता। हर एक में वह शामिल है।

1. संख्याओं के प्रकार

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

“इंटरफ़ेस विफलता” की लागत को एकल वार्षिक योग के रूप में बताने वाले आँकड़े बिना किसी घोषित पद्धति के प्रचलित हैं। खंड 3 के प्राथमिक अनुमानों में से कोई भी इंटरफ़ेस को अलग नहीं करता, इसलिए यह निबंध उन्हें किसी एकल योग पर नहीं बिठाता।

2. एकल विफलताएँ, लेखांकित

Mars Climate Orbiter। इंटरफ़ेस एक इकाई थी: पाउंड-बल सेकंड में दिए गए थ्रस्टर आवेग आँकड़ों को न्यूटन सेकंड के रूप में पढ़ा गया [2]। NASA की परियोजना तथ्य-पत्रिका Mars Surveyor 1998 परियोजना की लागत ऑर्बिटर और Mars Polar Lander दोनों के लिए मिलाकर $327.6 मिलियन बताती है: अंतरिक्ष यान विकास के लिए $193.1 मिलियन, लॉन्च के लिए $91.7 मिलियन और संचालन के लिए $42.8 मिलियन [1]। समकालीन रिपोर्टों ने अकेले ऑर्बिटर को $125 मिलियन का अंतरिक्ष यान बताया [3]। प्रकार: परियोजना की लेखांकित लागत, साथ में एक अंतरिक्ष यान के लिए बताया गया आँकड़ा।

Ariane 501 और Cluster। इंटरफ़ेस एक आवरण था: Ariane 4 से पुनः उपयोग किया गया सॉफ़्टवेयर क्षैतिज वेग की एक ऐसी परास मानकर चलता था जिसे नया लॉन्चर पार कर गया [5]। चारों Cluster उपग्रह खो गए। पुनर्प्राप्ति के बारे में ESA का विवरण उन विकल्पों को दर्ज करता है जिनकी कीमत उसकी Science Programme Committee ने 1996 में आँकी थी, जिनमें चारों उपग्रहों को मूल डिज़ाइन के अनुसार फिर से बनाने के लिए 351 मिलियन लेखा इकाइयाँ शामिल थीं, और ESA ने 1997 में 214 मिलियन ECU में एक पुनर्प्राप्ति मिशन, Cluster II, स्वीकृत किया [4, 17]। प्रकार: ESA द्वारा चुनी गई पुनर्प्राप्ति की लेखांकित लागत, जो हानि की एक निचली सीमा है, उपग्रहों का या विलंबित विज्ञान का मूल्य नहीं।

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

3. राष्ट्रीय अनुमान, मॉडल किए गए

इस निबंध में उद्धृत प्राथमिक अनुमानों का लघुगणकीय डॉलर अक्ष पर बार चार्ट, प्रकार के अनुसार रंगा हुआ। लेखांकित लागतें: Mars Surveyor 1998 परियोजना 327.6 मिलियन डॉलर और Cluster II पुनर्प्राप्ति 214 मिलियन ECU। मॉडल अनुमान: NIST 2004, अमेरिकी पूंजीगत सुविधाओं में अपर्याप्त अंतरसंचालनीयता, 15.8 बिलियन डॉलर प्रति वर्ष; NIST 2002, अपर्याप्त सॉफ़्टवेयर परीक्षण अवसंरचना, 59.5 बिलियन डॉलर प्रति वर्ष; Stripe 2018, खराब कोड पर डेवलपरों का समय, लगभग 85 बिलियन डॉलर प्रति वर्ष; CISQ 2022, तकनीकी ऋण, लगभग 1.52 ट्रिलियन डॉलर संचित; CISQ 2022, अमेरिका में खराब सॉफ़्टवेयर गुणवत्ता की लागत, 2022 में कम से कम 2.41 ट्रिलियन डॉलर।
चित्र 1. प्रकार के अनुसार अनुमान। डेटा चित्र, लघुगणकीय अक्ष। मान वैसे ही हैं जैसे स्रोतों ने छापे हैं [1, 4, 6, 7, 8, 9]। बार जोड़ने योग्य नहीं हैं: CISQ के योग में ऐसी श्रेणियाँ हैं जो NIST और Stripe के आँकड़ों से अतिव्याप्त होती हैं, और एक भंडार (तकनीकी ऋण) वार्षिक प्रवाहों के साथ दिखाया गया है। एक PNG प्रति उपलब्ध है। Open full size · PNG

सॉफ़्टवेयर परीक्षण, NIST 2002। RTI International ने NIST के लिए अनुमान लगाया कि सॉफ़्टवेयर परीक्षण की अपर्याप्त अवसंरचना से अमेरिकी अर्थव्यवस्था को प्रति वर्ष $22.2 बिलियन से $59.5 बिलियन की लागत आई, जिसमें ऊपरी आँकड़ा कुल लागत है और निचला आँकड़ा वह हिस्सा है जिसे व्यवहार्य सुधार हटा सकते हैं [6]। पद्धति ने दो क्षेत्रों, परिवहन विनिर्माण और वित्तीय सेवाओं, के डेवलपरों और उपयोगकर्ताओं के सर्वेक्षणों को राष्ट्रीय अर्थव्यवस्था तक एक बहिर्वेशन के साथ जोड़ा। प्रकार: मॉडल अनुमान।

अंतरसंचालनीयता, NIST 2004। Gallaher और सहयोगियों ने NIST के लिए मालिकों, संचालकों, वास्तुकारों, इंजीनियरों और ठेकेदारों के साक्षात्कारों और सर्वेक्षणों से अमेरिकी पूंजीगत सुविधा उद्योग में अपर्याप्त अंतरसंचालनीयता की लागत $15.8 बिलियन प्रति वर्ष आँकी [7]। यहाँ अंतरसंचालनीयता का अर्थ है सॉफ़्टवेयर प्रणालियों के बीच डिज़ाइन और परिचालन आँकड़ों का आदान-प्रदान और उपयोग कर पाने की क्षमता, जो सारांश में परिभाषित अर्थ में एक इंटरफ़ेस है। रिपोर्ट कहती है कि उसके आँकड़े में वे लागतें शामिल नहीं हैं जिन्हें वह परिमाणित नहीं कर सकी। प्रकार: मॉडल अनुमान, एक उद्योग, रूढ़िवादी आँकड़े के रूप में प्रस्तुत।

खराब सॉफ़्टवेयर गुणवत्ता, CISQ 2022। Consortium for Information and Software Quality ने अनुमान लगाया कि संयुक्त राज्य अमेरिका में खराब सॉफ़्टवेयर गुणवत्ता की लागत 2022 में बढ़कर कम से कम $2.41 ट्रिलियन हो गई थी, और संचित तकनीकी ऋण बढ़कर लगभग $1.52 ट्रिलियन हो गया था [8]। रिपोर्ट कुल योग श्रेणियों से बनाती है, यानी परिचालन विफलताएँ, असफल परियोजनाएँ, पुरानी प्रणालियों की समस्याएँ और सॉफ़्टवेयर कमज़ोरियों से जुड़ी साइबर अपराध हानियाँ, और अपने इनपुट का बड़ा हिस्सा द्वितीयक स्रोतों से लेती है; इसका साइबर अपराध घटक एक वैश्विक पूर्वानुमान का एक भाग संयुक्त राज्य अमेरिका को आवंटित करता है [8]। प्रकार: आंशिक रूप से अन्य अनुमानों पर बना मॉडल अनुमान। यह इस क्षेत्र का सबसे बड़ा प्रलेखित आँकड़ा है, और यह समग्र रूप से सॉफ़्टवेयर गुणवत्ता का आँकड़ा है, इंटरफ़ेस का नहीं।

डेवलपर का समय, Stripe 2018। Harris Poll के साथ किए गए Stripe के एक सर्वेक्षण ने बताया कि डेवलपर डिबगिंग और रीफ़ैक्टरिंग जैसे रखरखाव कार्य पर प्रति सप्ताह लगभग 17.3 घंटे बिताते हैं, और “खराब कोड” पर प्रति सप्ताह लगभग चार घंटे, जिसका मूल्य रिपोर्ट विश्व भर में प्रति वर्ष लगभग $85 बिलियन आँकती है [9]। प्रकार: सर्वेक्षण पर आधारित अनुमान।

इन आँकड़ों में जो साझा है वह एक संरचना है, कोई योग नहीं। हर एक उस धारणा की लागत गिनता है जिस पर निर्भर रहा गया और जिसे जाँचा नहीं गया: एक अपरीक्षित पथ, एक डेटा प्रारूप जो पार नहीं जाता, किसी सीमा पर एक कमज़ोरी, एक पुरानी प्रणाली जिसके अनुबंधों को अब कोई फिर से नहीं बता सकता। जो बेमेल वहीं नहीं जाँचा जाता जहाँ वह उत्पन्न होता है, वह अपने ऊपर के हर स्तर तक सुगठित इनपुट के रूप में पहुँचता है, इसलिए उसकी लागत उसके कारण से बहुत दूर प्रकट होती है, जैसे Mars Climate Orbiter के नेविगेशन समाधान में, जो आंतरिक रूप से सुसंगत था और गलत था [2]। यही कारण है कि राष्ट्रीय अनुमानों को गिना नहीं, मॉडल किया जाना पड़ता है।

4. तकनीकी ऋण एक इंटरफ़ेस खाता है

Cunningham ने 1992 में तकनीकी ऋण की अवधारणा ऐसे कोड को शिप करने की लागत के रूप में पेश की जिसकी संरचना अभी उससे मेल नहीं खाती जो टीम ने सीखा है, और जिस पर ऋण चुकाए जाने तक हर बाद के बदलाव पर ब्याज चुकाया जाता है [10]। Sculley और सहयोगियों ने दिखाया कि मशीन लर्निंग प्रणालियों में उस ऋण का अधिकांश हिस्सा मॉडल के बाहर रहता है, ग्लू कोड, कॉन्फ़िगरेशन, डेटा निर्भरताओं और अघोषित उपभोक्ताओं में [11]। ऊपर परिभाषित शब्दों में, तकनीकी ऋण का बड़ा हिस्सा बही-खातों में दर्ज अपरीक्षित इंटरफ़ेस धारणाओं का शेष है, और उसका ब्याज वह लागत है जो एक अनजाँचा बेमेल अपने ऊपर के हर स्तर से, हर रन पर, वसूलता है।

संयुक्त राज्य अमेरिका में लगभग $1.52 ट्रिलियन के संचित तकनीकी ऋण का CISQ का अनुमान एक भंडार है, जिसे ठीक करने की लागत में मापा गया है [8]। खंड 3 के वार्षिक आँकड़े प्रवाह हैं। आर्थिक परिणाम एक परिकल्पना है, जिसका परीक्षण खंड 7 में है: किसी सीमा पर एक बार चुकाई गई जाँच किसी कार्यभार पर उस विफलता से कम लागत की हो सकती है जो हर उस स्तर पर बार-बार चुकाई जाती है जहाँ तक वह पहुँचती है।

5. मानक वह तरीका हैं जिससे बाज़ार इंटरफ़ेस बंद करते हैं

अर्थशास्त्रियों ने दशकों तक इंटरफ़ेस समस्या का अध्ययन एक और नाम से किया है: संगतता। Katz और Shapiro ने दिखाया कि जब किसी उत्पाद का मूल्य उन उपयोगकर्ताओं की संख्या के साथ बढ़ता है जिनके साथ वह काम कर सकता है, तो संगत होने के लिए फ़र्मों के प्रोत्साहन उनके आकार और स्थिति पर निर्भर करते हैं, और बाज़ार बहुत कम संगतता दे सकता है [12]। Farrell और Saloner ने दिखाया कि कोई बाज़ार किसी पुराने मानक पर अटका रह सकता है, या किसी नए मानक पर बहुत तेज़ी से चला जा सकता है, क्योंकि हर उपयोगकर्ता का चुनाव इस पर निर्भर करता है कि दूसरे क्या चुनते हैं [13]। QWERTY कीबोर्ड के David के इतिहास ने पथ निर्भरता को ठोस बनाया [14]। Baldwin और Clark ने दिखाया कि डिज़ाइन नियम, यानी पहले से तय दृश्य इंटरफ़ेस, ही वह चीज़ हैं जो मॉड्यूलर उद्योगों को बनने देते हैं [15]। ब्रिटेन सरकार के लिए Swann की समीक्षा ने उन प्रमाणों का सार दिया कि मानक उत्पादकता और व्यापार में योगदान करते हैं [16]।

साझा सूत्र यह है कि इंटरफ़ेस निजी लागतों वाली एक सार्वजनिक वस्तु है। किसी धारणा को लिखना और जाँचना सीमा पार करने वाले हर पक्ष को लाभ देता है, पर उसका भुगतान वही करता है जो लिखता है। हर पक्ष के पास हस्तांतरण को किसी और का काम मानने का कारण है। मानक निकाय, नियामक और प्लेटफ़ॉर्म मालिक वे संस्थाएँ हैं जिन्होंने ऐतिहासिक रूप से यह लागत चुकाई है। मशीन द्वारा जाँचे जाने वाले निरूपण, जैसे माप की इकाइयाँ साथ रखने वाले टाइप या मॉडल चेकर द्वारा जाँचे गए औपचारिक विनिर्देश [21, 22], किसी इंटरफ़ेस को बंद करने की निजी लागत को उसकी जाँच चलाने की लागत की ओर घटा देते हैं।

6. उत्पन्न कोड उन्हीं इंटरफ़ेस को पार करता है

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

7. प्रस्थापनाएँ और प्रोटोकॉल

प्रस्थापना E1 (इंटरफ़ेस का हिस्सा)। लेखांकित लागतों वाली सॉफ़्टवेयर विफलताओं की किसी समष्टि में, लागत का वह हिस्सा जिसका कारण सारांश में परिभाषित अर्थ में एक उल्लंघित इंटरफ़ेस धारणा है, उस हिस्से से अधिक है जिसका कारण पूरी तरह एक ही निकाय के भीतर है।

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

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

प्रोटोकॉल। ऐसी प्रणाली पर जिसके स्तरों की परिचालन लागतें ज्ञात हैं, एक निश्चित seed समुच्चय पर हर दर्ज इंटरफ़ेस धारणा का उल्लंघन इंजेक्ट करें, और हर जाँच की लागत तथा हर न पकड़े गए उल्लंघन की लागत वहाँ दर्ज करें जहाँ वह पहुँचता है। दोनों को जूल में और एक घोषित मूल्य पर डॉलर में रिपोर्ट करें।

प्रस्थापना E3 (इंटरफ़ेस बंद करने से उसकी निजी लागत घटती है)। जब इंटरफ़ेस धारणा किसी साझा निरूपण का हिस्सा हो और निर्माण से ही जाँची जाती हो, तो किसी एक पक्ष के लिए उसे बंद करने की लागत उसकी जाँच चलाने की लागत की ओर गिरती है।

प्रोटोकॉल। संगठनों के बीच कोई वास्तविक हस्तांतरण चुनें, जैसे किसी कार्यान्वयनकर्ता को सौंपा गया विनिर्देश। एक शाखा में इसे गद्य दस्तावेज़ीकरण के रूप में और दूसरी में मशीन द्वारा जाँचे जाने वाले निरूपण के रूप में ले जाएँ। हस्तांतरण के दोनों पक्षों पर श्रम घंटे और हर शाखा में इंटरफ़ेस पर स्थित विफलताएँ Wilson 95% अंतरालों के साथ दर्ज करें।

8. निष्कर्ष

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

संदर्भ

[1] NASA Jet Propulsion Laboratory, “Mars Climate Orbiter Fact Sheet,” Mars Surveyor 1998 project. Archived copy: https://web.archive.org/web/20121003073752/http://mars.jpl.nasa.gov/msp98/orbiter/fact.html

[2] Mars Climate Orbiter Mishap Investigation Board, Phase I Report. NASA, 10 November 1999. https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf

[3] A. Pollack, “Two Teams, Two Measures Equaled One Lost Spacecraft,” The New York Times, 1 October 1999. https://archive.nytimes.com/www.nytimes.com/library/national/science/100199sci-nasa-mars.html

[4] European Space Agency, “Cluster will fly again!,” press release N° 12 1997, 26 March 1997. https://www.esa.int/Newsroom/Press_Releases/Cluster_will_fly_again

[5] J. L. Lions (chair), Ariane 5 Flight 501 Failure: Report by the Inquiry Board. European Space Agency, 19 July 1996. https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf

[6] RTI International for the National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, May 2002. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf

[7] M. P. Gallaher, A. C. O’Connor, J. L. Dettbarn and L. T. Gilday, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry, NIST GCR 04-867, 2004. doi:10.6028/NIST.GCR.04-867

[8] H. Krasner, The Cost of Poor Software Quality in the US: A 2022 Report. Consortium for Information and Software Quality, 2022. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/

[9] Stripe, The Developer Coefficient, with Harris Poll, September 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf

[10] W. Cunningham, “The WyCash portfolio management system,” OOPSLA 1992 Addendum, ACM SIGPLAN OOPS Messenger 4(2), 1993, pp. 29 to 30. doi:10.1145/157710.157715

[11] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo and D. Dennison, “Hidden Technical Debt in Machine Learning Systems,” Advances in Neural Information Processing Systems 28, 2015. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

[12] M. L. Katz and C. Shapiro, “Network Externalities, Competition, and Compatibility,” American Economic Review 75(3), June 1985, pp. 424 to 440. RePEc:aea:aecrev:v:75:y:1985:i:3:p:424-40. https://www.jstor.org/stable/1814809

[13] J. Farrell and G. Saloner, “Standardization, Compatibility, and Innovation,” RAND Journal of Economics 16(1), 1985, pp. 70 to 83. doi:10.2307/2555589

[14] P. A. David, “Clio and the Economics of QWERTY,” American Economic Review 75(2), Papers and Proceedings, May 1985, pp. 332 to 337. RePEc:aea:aecrev:v:75:y:1985:i:2:p:332-37. https://www.jstor.org/stable/1805621

[15] C. Y. Baldwin and K. B. Clark, Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. doi:10.7551/mitpress/2366.001.0001

[16] G. M. P. Swann, The Economics of Standardization: An Update. Report for the UK Department for Business, Innovation and Skills, 2010. https://www.gov.uk/government/publications/economics-of-standardisation-update-to-report

[17] European Space Agency, “The Resurrection of the Cluster Scientific Mission,” ESA Bulletin 91, 1997. https://www.esa.int/esapub/bulletin/bullet91/b91cred.htm

[19] D. Garlan, R. Allen and J. Ockerbloom, “Architectural mismatch: why reuse is so hard,” IEEE Software 12(6), 1995, pp. 17 to 26. doi:10.1109/52.469757

[20] N. G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2012. doi:10.7551/mitpress/8179.001.0001

[21] A. Kennedy, “Types for Units-of-Measure: Theory and Practice,” in Central European Functional Programming School, Lecture Notes in Computer Science 6299, Springer, 2010, pp. 268 to 305. doi:10.1007/978-3-642-17685-2_8

[22] C. Newcombe, T. Rath, F. Zhang, B. Munteanu, M. Brooker and M. Deardeuff, “How Amazon Web Services uses formal methods,” Communications of the ACM 58(4), 2015, pp. 66 to 73. doi:10.1145/2699417