तकनीकी ऋण: Difference between revisions

Latest revision as of 17:07, 25 May 2023

सॉफ़्टवेयर विकास में तकनीकी ऋण को डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है।^[1] अपेक्षाकृत दृष्टिकोण के अतिरिक्त एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।^[2]

आर्थिक ऋण के अनुरूप यदि तकनीकी ऋण का भुगतान नहीं किया जाता है तो यह "ब्याज" को अधिक कर सकता है।^[3] जिससे परिवर्तनों को प्रयुक्त करना कठिन हो जाता है। अतिरिक्त किसी संबोधन के तकनीकी ऋण सॉफ्टवेयर एन्ट्रापी और आगे के पुनःकार्य की लागत को बढ़ाता है। इसी प्रकार आर्थिक ऋण के लिए तकनीकी ऋण एक अनैतिक वस्तु नहीं है और कभी-कभी उदाहरण के लिए अवधारणा के प्रमाण के रूप में परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर कुछ विशेषज्ञों का कथन है कि "तकनीकी ऋण" रूपक प्रभाव को कम करता है। जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है।^[4]^[5]

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

2016 में आयोजित एक डगस्टुहल सेमिनार में तकनीकी ऋण को विषय के शैक्षणिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था। "सॉफ्टवेयर गहन प्रणालियों में तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अपेक्षाकृत कम समय में कार्य करने योग्य है। लेकिन एक निर्धारित तकनीकी संदर्भ है जो भविष्य के परिवर्तनों को अधिक कीमती या असंभव बना सकता है। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है। जिसका प्रभाव आंतरिक प्रणाली गुणों, मुख्य रूप से संरक्षण और अस्थिरता तक सीमित होता है।^[6]

कारण

तकनीकी ऋण के सामान्य कारणों में सम्मिलित हैं:

प्रारम्भिक को समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उनके विकास के अनुकूल बना देती है।
अपर्याप्त पहले की परिभाषा मे जहां विकास के समय आवश्यकताओं को अभी भी परिभाषित किया जा रहा है। किसी भी डिजाइन के होने से पहले विकास प्रारम्भ हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन प्रायः बाद में इसे फिर से कार्य करना पड़ता है।
व्यावसायिक दाब, जहां आवश्यक परिवर्तन पूर्ण होने से पहले व्यवसाय शीघ्र ही कुछ प्रारम्भ करने पर विचार करता है। और उन अधूरे परिवर्तनों को सम्मिलित करते हुए तकनीकी ऋण का निर्माण करता है।^[7]^: 4^[8]^: 22
प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अप्रत्यक्ष होते हैं। और निहितार्थों पर विचार किए बिना निर्णय लेते हैं।
युग्मन (कंप्यूटर प्रोग्रामिंग) , जहां कार्य मॉड्यूलर प्रोग्रामिंग नहीं हैं, सॉफ्टवेयर इतना नम्य नहीं होता है कि वह व्यावसायिक आवश्यकताओ में परिवर्तन के अनुकूल हो सके।
परीक्षण सूट का अभाव, जो त्वरित और जोखिम से पूर्ण बैंड-ऐड (कम्प्यूटिंग) बग निर्धारण को प्रोत्साहित करता है।
सॉफ़्टवेयर दस्तावेज़ों का अभाव, जहाँ दस्तावेज़ों का समर्थन किए बिना कोड बनाया जाता है। दस्तावेज़ बनाने का कार्य ऋण का प्रतिनिधित्व करता है।^[7]
सहयोग का अभाव, जहां ज्ञान को संगठन के आसपास साझा नहीं किया जाता है और व्यावसायिक दक्षता प्रभावित होती है या जूनियर विकासक को ठीक से सलाह नहीं दी जाती है।
एक स्रोत आधार में परिवर्तनों को संयुक्त करने के लिए आवश्यक कार्य के कारण कई शाखाओं पर समानांतर विकास तकनीकी ऋण उपस्थित होता है। अंतर्राष्ट्रीय स्थिति में जितने अधिक परिवर्तन किए जाते हैं उतना अधिक ऋण होता है।
स्थगित कोड पुनर्रचना, जैसे-जैसे किसी परियोजना के लिए आवश्यकताएँ विकसित होती हैं वैसे ही यह स्पष्ट हो सकता है कि कोड के भाग अक्षम या संपादित करने में कठिन हो गए हैं और भविष्य की आवश्यकताओं का समर्थन करने के लिए उन्हें फिर से तैयार किया जाना चाहिए। जितनी लंबी पुनर्रचना में देरी होती है और जितना अधिक कोड जोड़ा जाता है उतना ही अधिक ऋण हो सकता है।^[8]^: 29
मानकों के संरेखण की कमी, जहां उद्योग मानक सुविधाओं, सॉफ्टवेयर संरचना और प्रौद्योगिकियों को अस्वीकृत करते है। अंत मे मानकों के साथ एकीकरण आ सकता है और ऐसा करने में शीघ्र ही विलंबित पुनर्रचना के समान कम खर्च लग सकती है।^[7]^: 7
ज्ञान की कमी, जब विकासक को यह नहीं पता होता है कि सहज कोड कैसे लिखना है।^[8]
अंतिम मिनट विनिर्देश परिवर्तन, इनमें एक परियोजना के समय प्रसारित होने की क्षमता है। लेकिन परिवर्तनों का दस्तावेजीकरण और परीक्षण करने के लिए अपर्याप्त समय या बजट है।
स्वामित्व की कमी, जब बाह्‌य स्रोत किए गए सॉफ़्टवेयर प्रयासों के परिणामस्वरूप घरेलू अभियांत्रिकी को कोड पुनर्रचना या कोड पुनर्लेखन बाह्‌य स्रोत कोड की आवश्यकता होती है।
तुच्छ तकनीकी नेतृत्व, जहां तुच्छ तरीके से विचार किए गए प्रयासों को निर्धारित शृंखला के साथ प्रयुक्त किया जाता है।

सेवा या तकनीकी ऋण भुगतान

केनी रुबिन निम्न स्थिति श्रेणियों का उपयोग करता है:^[9]

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

परिणाम

"ब्याज भुगतान" आवश्यक स्थानीय संरक्षण और परियोजना के अन्य उपयोगकर्ताओं द्वारा संरक्षण की अनुपस्थिति दोनों के कारण होता है। प्रतिप्रवाह परियोजना में चल रहे विकास से भविष्य में "ऋण भुगतान" की लागत बढ़ सकती है।^{[clarification needed]} केवल अपूर्ण कार्य को पूरा करके ऋण का भुगतान किया जा सकता है।^{[citation needed]}

तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा की असफलता का एक प्रमुख कारण है।^{[citation needed]} यह अनुमान लगाना कठिन है कि ऋण का भुगतान करने के लिए कितना कार्य आवश्यक है। प्रत्येक परिवर्तन के लिए जो प्रारम्भ किया गया है। वह परियोजना के लिए अपूर्ण कार्य की अनिश्चित राशि प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। पूर्वानुमेय प्रकाशन अनुक्रम के लिए एक विकास समुदाय को अपूर्ण की मात्रा को बनाए रखने के लिए कार्य की मात्रा को सीमित करना चाहिए जिससे कार्य (या कर्ज) प्रत्येक समय अपेक्षाकृत कम हो सकता है।^{[citation needed]}

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

"एक विकसित कार्य के रूप में निरंतर परिवर्तन होता रहता है इसकी जटिलता, ह्रासित संरचना को दर्शाती है। जब तक इसे बनाए रखने या कम करने के लिए कार्य नहीं किया जाता है।"^[10]
— मीर मैनी लेहमन, 1980

जबकि मीर मैनी लेहमन के नियम ने पहले ही संकेत दिया था कि विकसित कार्य निरंतर उनकी जटिलता और ह्रासित संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए कार्य नहीं किया जाता है। वार्ड कनिंघम ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना किया था:

"अपरिपक्व समुदाय पहली बार कोड ऋण में जाने जैसा होता है। एक छोटा सा ऋण विकास को तब तक गति देता है जब तक इसे पुनर्लेखन के साथ शीघ्र वापस भुगतान किया जाता है। इसमे जोखिम तब होता है जब ऋण भुगतान नहीं जाता है। पूर्णतः सही कोड पर बिताया गया प्रत्येक मिनट उस ऋण पर ब्याज के रूप में गिना जाता है। संपूर्ण इंजीनियरिंग संगठनों को एक असमेकित कार्यान्वयन वस्तु उन्मुख के ऋण भार के अंतर्गत स्थिर किया जा सकता है। "^[11]
— वार्ड कनिंघम, 1992

जोशुआ केरिवेस्की वास्तु ने अपने 2004 के लेख में पुनर्रचना पैटर्न कमी से संबद्ध लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत किया है। जिसे वह "डिजाइन ऋण" के रूप में वर्णित करते है।^[12]

जिन गतिविधियों को स्थगित किया जा सकता है उनमें दस्तावेज़ीकरण, परीक्षण स्वचालन, टीओडीओ टिप्पणियों पर ध्यान देना, संकलक और स्थैतिक कोड विश्लेषण चेतावनियों का सामना करना सम्मिलित है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान सम्मिलित है। जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।^{[citation needed]}

2014 में पीएचपी के विकास के विषय में लिखते हुए, जुनादे अली ने कहा कि:

इस तकनीकी ऋण को कभी न भुगतान करने की कीमत स्पष्ट है अंततः कार्यक्षमता प्रदान करने की लागत इतनी धीमी हो सकती है कि एक अच्छी तरह से डिज़ाइन किए गए प्रतिस्पर्धी सॉफ़्टवेयर उत्पाद के लिए सुविधाओं कि स्थिति में डिज़ाइन किए गए सॉफ़्टवेयर से आगे निकलना आसान हो सकता है मेरे अनुभव में, अपेक्षाकृत असहज प्रकार से डिज़ाइन किया गया सॉफ़्टवेयर भी एक अधिक तनावग्रस्त इंजीनियरिंग कार्यबल का कारण बन सकता है। जिसके परिणामस्वरूप उच्च कर्मचारी मंथन होता है जो सुविधाओं को वितरित करते समय लागत और उत्पादकता को प्रभावित करता है। इसके अतिरिक्त किसी दिए गए कोडबेस में जटिलता के कारण कार्य का शुद्ध अनुमान लगाने की क्षमता भी लुप्त हो सकती है। ऐसी स्थिति में जहां विकास संस्थाए विशिष्ट गुण के आधार पर चार्ज करती हैं। जिससे कोड अभिगम्य करने के लिए लाभ दर अंततः नष्ट हो सकती है।
— जुनादे अली, ''प्राप्त पीएचपी डिजाइन पैटर्न''^[13]

ग्रेडी बूच ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर सघन प्रणालियों के विकास के समान हैं और पुनर्रचना की कमी कैसे तकनीकी ऋण का कारण बन सकती है।

तकनीकी ऋण की अवधारणा उन वस्तुओ को समझने के लिए केंद्रीय है जो प्रणाली पर भारित हैं क्योंकि ये प्रायः करती है कि प्रणाली कहां, कैसे और क्यों तनावग्रस्त है। कई शहरों में आधारिक संरचना के संरक्षण में प्रायः देरी होती है और बड़े परिवर्तन के अतिरिक्त वृद्धिशील परिवर्तन किए जाते हैं। तो यह फिर से सॉफ्टवेयर गहन प्रणालियों में है। उपयोगकर्ताओं को अपेक्षाकृत जटिलता, विलंबित सुधार और अपर्याप्त वृद्धिशील परिवर्तन के परिणाम का सामना करना पड़ता हैं। विकासक जो इस प्रकार की प्रणाली को विकसित करते हैं। वे कभी भी गुणवत्ता कोड लिखने में सक्षम नहीं होने के संकेत और चिन्ह को पीड़ित करते हैं क्योंकि वे सदैव अभिग्रहण का प्रयास करते हैं।^[1]
— ग्रेडी बूच, 2014

मुक्त स्रोत सॉफ़्टवेयर में धारावाहिक परियोजना के स्थानीय परिवर्तन को भेजना या स्थगित करना तकनीकी ऋण का एक रूप है।^{[citation needed]}

यह भी देखें

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

संदर्भ

↑ ^1.0 ^1.1 Suryanarayana, Girish (November 2014). सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग (1st ed.). Morgan Kaufmann. p. 258. ISBN 978-0128013977.
↑ ""तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")". Techopedia. Retrieved August 11, 2016.
↑ Allman, Eric (May 2012). "तकनीकी ऋण का प्रबंधन". Communications of the ACM. 55 (5): 50–55. doi:10.1145/2160718.2160733. S2CID 53246391.
↑ Knesek, Doug. "Averting a 'Technical Debt' Crisis". Retrieved April 7, 2016.
↑ <ref> = जेफरीज़ 2015>Jeffries, Ron. "तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?". Archived from the original on November 11, 2015. Retrieved November 10, 2015.<nowiki>
↑ Avgeriou, Paris; Kruchten, Philippe; Ozkaya, Ipek; Carolyn, Seaman (2016). "Managing technical debt in software engineering (dagstuhl seminar 16162)" (PDF). Dagstuhl reports. 6 (4).
↑ ^7.0 ^7.1 ^7.2 Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 November 2014). Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
↑ ^8.0 ^8.1 ^8.2 Chris Sterling (10 December 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1.
↑ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English), Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
↑ Lehman, MM (1996). "Laws of Software Evolution Revisited". EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology: 108–124. ISBN 9783540617716. Retrieved 19 November 2014.
↑ Ward Cunningham (1992-03-26). "The WyCash Portfolio Management System". Retrieved 2008-09-26.
↑ Kerievsky, Joshua (2004). पैटर्न के लिए रिफैक्टरिंग. ISBN 978-0-321-21335-8.
↑ Ali, Junade (September 2016). Mastering PHP Design Patterns | PACKT Books (in English) (1 ed.). Birmingham, England, UK: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Retrieved 11 December 2017.

बाहरी संबंध

Ward Explains Debt Metaphor, video from Ward Cunningham
OnTechnicalDebt The online community for discussing technical debt
Experts interviews on Technical Debt: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY
Steve McConnell discusses technical debt
TechnicalDebt from Martin Fowler Bliki
Averting a "Technical Debt" Crisis by Doug Knesek
"Get out of Technical Debt Now!", a talk by Andy Lester
Lehman's Law
Managing Technical Debt Webinar by Steve McConnell
Boundy, David, Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US
Technical debt: investeer en voorkom faillissement by Colin Spoel
Technical debts: Everything you need to know
What is technical debt? from DeepSource blog

[Girish_2014-1] 1.0 ^1.1 Suryanarayana, Girish (November 2014). सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग (1st ed.). Morgan Kaufmann. p. 258. ISBN 978-0128013977.

[2] ""तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")". Techopedia. Retrieved August 11, 2016.

[Managing_Technical_Debt-3] Allman, Eric (May 2012). "तकनीकी ऋण का प्रबंधन". Communications of the ACM. 55 (5): 50–55. doi:10.1145/2160718.2160733. S2CID 53246391.

[Knesek_2016-4] Knesek, Doug. "Averting a 'Technical Debt' Crisis". Retrieved April 7, 2016.

[5] <ref> = जेफरीज़ 2015>Jeffries, Ron. "तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?". Archived from the original on November 11, 2015. Retrieved November 10, 2015.<nowiki>

[6] Avgeriou, Paris; Kruchten, Philippe; Ozkaya, Ipek; Carolyn, Seaman (2016). "Managing technical debt in software engineering (dagstuhl seminar 16162)" (PDF). Dagstuhl reports. 6 (4).

[SuryanarayanaSamarthyam2014-7] 7.0 ^7.1 ^7.2 Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 November 2014). Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. p. 3. ISBN 978-0-12-801646-6.

[Sterling2010-8] 8.0 ^8.1 ^8.2 Chris Sterling (10 December 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1.

[Essential_Scrum:_Velocity-9] Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English), Addison-Wesley, p. 155, ISBN 978-0-13-704329-3

[10] Lehman, MM (1996). "Laws of Software Evolution Revisited". EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology: 108–124. ISBN 9783540617716. Retrieved 19 November 2014.

[oopsla92-11] Ward Cunningham (1992-03-26). "The WyCash Portfolio Management System". Retrieved 2008-09-26.

[rtp-12] Kerievsky, Joshua (2004). पैटर्न के लिए रिफैक्टरिंग. ISBN 978-0-321-21335-8.

[13] Ali, Junade (September 2016). Mastering PHP Design Patterns | PACKT Books (in English) (1 ed.). Birmingham, England, UK: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Retrieved 11 December 2017.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

@@ Line 1: / Line 1: @@
 {{short description|Software development concept}}
-सॉफ्टवेयर विकास में, तकनीकी ऋण (डिजाइन ऋण के रूप में भी जाना जाता है<ref name="Girish 2014">{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258|edition=1st}}</ref> या कोड ऋण) एक बेहतर दृष्टिकोण के बजाय एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।<ref>{{cite web|url=https://www.techopedia.com/definition/27913/technical-debt|website=Techopedia|title="तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")|access-date=August 11, 2016}} </ref>
+सॉफ़्टवेयर विकास में '''तकनीकी ऋण''' को डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है।<ref name="Girish 2014">{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258|edition=1st}}</ref> अपेक्षाकृत दृष्टिकोण के अतिरिक्त एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।<ref>{{cite web|url=https://www.techopedia.com/definition/27913/technical-debt|website=Techopedia|title="तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")|access-date=August 11, 2016}} </ref>
-मौद्रिक ऋण के अनुरूप,<ref name="Managing_Technical_Debt">{{cite journal|last1=Allman|first1=Eric|title=तकनीकी ऋण का प्रबंधन|journal=Communications of the ACM|date=May 2012|volume=55|issue=5|pages=50–55|doi=10.1145/2160718.2160733|s2cid=53246391 }}</ref> यदि तकनीकी ऋण का भुगतान नहीं किया जाता है, तो यह ब्याज जमा कर सकता है, जिससे परिवर्तनों को लागू करना कठिन हो जाता है। अनएड्रेस्ड टेक्निकल डेट [[सॉफ्टवेयर एन्ट्रापी]] और आगे के रीवर्क की लागत को बढ़ाता है। इसी तरह मौद्रिक ऋण के लिए, तकनीकी ऋण एक बुरी चीज नहीं है, और कभी-कभी (उदाहरण के लिए अवधारणा के प्रमाण के रूप में) परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर, कुछ विशेषज्ञों का दावा है कि तकनीकी ऋण रूपक प्रभाव को कम करता है, जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है। रेफरी नाम = जेफरीज़ 2015>{{cite web| last=Jeffries|first=Ron|access-date=November 10, 2015|url=http://ronjeffries.com/articles/015-11/tech-debt/|archive-url=https://web.archive.org/web/20151111011323/http://ronjeffries.com/articles/015-11/tech-debt/|archive-date=November 11, 2015 |title=तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?}}</ref><ref name="Knesek 2016">{{cite web| last=Knesek|first=Doug|access-date=April 7, 2016|url=https://www.linkedin.com/pulse/averting-technical-debt-crisis-part-1-doug-knesek|title=Averting a 'Technical Debt' Crisis}}</ref>
-जैसे ही एक कोडबेस पर बदलाव शुरू किया जाता है, कोडबेस या दस्तावेज़ीकरण के अन्य भागों में अक्सर अन्य समन्वित परिवर्तन करने की आवश्यकता होती है। आवश्यक परिवर्तन जो पूरे नहीं हुए हैं, उन्हें ऋण माना जाता है, और जब तक भुगतान नहीं किया जाता है, तब तक ब्याज के ऊपर ब्याज लगेगा, जिससे परियोजना का निर्माण बोझिल हो जाएगा। हालाँकि यह शब्द मुख्य रूप से सॉफ्टवेयर विकास में उपयोग किया जाता है, इसे अन्य व्यवसायों पर भी लागू किया जा सकता है।
-में आयोजित एक Dagstuhl#संगोष्ठी श्रृंखला में, तकनीकी ऋण को विषय के अकादमिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था: सॉफ्टवेयर-गहन प्रणालियों में, तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अल्पावधि में समीचीन है, लेकिन एक तकनीकी संदर्भ स्थापित करें जो भविष्य के परिवर्तनों को अधिक महंगा या असंभव बना सके। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है जिसका प्रभाव आंतरिक प्रणाली के गुणों तक सीमित है, मुख्य रूप से रखरखाव और अस्थिरता। .<ref>{{cite journal |last1=Avgeriou |first1=Paris |last2=Kruchten |first2=Philippe |last3=Ozkaya |first3=Ipek |last4=Carolyn |first4=Seaman |title=Managing technical debt in software engineering (dagstuhl seminar 16162) |journal=Dagstuhl reports |date=2016 |volume=6 |issue=4 | url=https://drops.dagstuhl.de/opus/volltexte/2016/6693/pdf/dagrep_v006_i004_p110_s16162.pdf#page=3}}</ref>
+आर्थिक ऋण के अनुरूप यदि तकनीकी ऋण का भुगतान नहीं किया जाता है तो यह "ब्याज" को अधिक कर सकता है।<ref name="Managing_Technical_Debt">{{cite journal|last1=Allman|first1=Eric|title=तकनीकी ऋण का प्रबंधन|journal=Communications of the ACM|date=May 2012|volume=55|issue=5|pages=50–55|doi=10.1145/2160718.2160733|s2cid=53246391 }}</ref> जिससे परिवर्तनों को प्रयुक्त करना कठिन हो जाता है। अतिरिक्त किसी संबोधन के तकनीकी ऋण [[सॉफ्टवेयर एन्ट्रापी]] और आगे के पुनःकार्य की लागत को बढ़ाता है। इसी प्रकार आर्थिक ऋण के लिए तकनीकी ऋण एक अनैतिक वस्तु नहीं है और कभी-कभी उदाहरण के लिए अवधारणा के प्रमाण के रूप में परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर कुछ विशेषज्ञों का कथन है कि "तकनीकी ऋण" रूपक प्रभाव को कम करता है। जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है।<ref name="Knesek 2016">{{cite web| last=Knesek|first=Doug|access-date=April 7, 2016|url=https://www.linkedin.com/pulse/averting-technical-debt-crisis-part-1-doug-knesek|title=Averting a 'Technical Debt' Crisis}}</ref><ref><nowiki><ref> = जेफरीज़ 2015></nowiki>{{cite web| last=Jeffries|first=Ron|access-date=November 10, 2015|url=http://ronjeffries.com/articles/015-11/tech-debt/|archive-url=https://web.archive.org/web/20151111011323/http://ronjeffries.com/articles/015-11/tech-debt/|archive-date=November 11, 2015 |title=तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?}}&lt;nowiki&gt;</ref>
+जैसे ही एक कोडबेस पर रूपांतरण प्रारम्भ किया जाता है तब कोडबेस या दस्तावेज़ीकरण के अन्य भागों में प्रायः अन्य समन्वित परिवर्तन करने की आवश्यकता होती है। आवश्यक परिवर्तन जो पूरे नहीं हुए हैं उन्हें ऋण माना जाता है और जब तक भुगतान नहीं किया जाता है। तब तक ब्याज के ऊपर ब्याज लगता है। जिससे परियोजना का निर्माण अधिक जटिल हो जाता है। हालाँकि यह शब्द मुख्य रूप से सॉफ्टवेयर विकास में उपयोग किया जाता है। इसे अन्य व्यवसायों पर भी प्रयुक्त किया जा सकता है।
+में आयोजित एक डगस्टुहल सेमिनार में तकनीकी ऋण को विषय के शैक्षणिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था। "सॉफ्टवेयर गहन प्रणालियों में तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अपेक्षाकृत कम समय में कार्य करने योग्य है। लेकिन एक निर्धारित तकनीकी संदर्भ है जो भविष्य के परिवर्तनों को अधिक कीमती या असंभव बना सकता है। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है। जिसका प्रभाव आंतरिक प्रणाली गुणों, मुख्य रूप से संरक्षण और अस्थिरता तक सीमित होता है।<ref>{{cite journal |last1=Avgeriou |first1=Paris |last2=Kruchten |first2=Philippe |last3=Ozkaya |first3=Ipek |last4=Carolyn |first4=Seaman |title=Managing technical debt in software engineering (dagstuhl seminar 16162) |journal=Dagstuhl reports |date=2016 |volume=6 |issue=4 | url=https://drops.dagstuhl.de/opus/volltexte/2016/6693/pdf/dagrep_v006_i004_p110_s16162.pdf#page=3}}</ref>
 == कारण ==
-{{more references needed section|date=October 2022}}
+तकनीकी ऋण के सामान्य कारणों में सम्मिलित हैं:
-तकनीकी ऋण के सामान्य कारणों में शामिल हैं:
+* प्रारम्भिक को समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उनके विकास के अनुकूल बना देती है।
-* चल रहे विकास, समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उप-इष्टतम बना देती है।
+* अपर्याप्त पहले की परिभाषा मे जहां विकास के समय आवश्यकताओं को अभी भी परिभाषित किया जा रहा है। किसी भी डिजाइन के होने से पहले विकास प्रारम्भ हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन प्रायः बाद में इसे फिर से कार्य करना पड़ता है।
-* अपर्याप्त अप-फ्रंट परिभाषा, जहां विकास के दौरान आवश्यकताओं का विश्लेषण अभी भी परिभाषित किया जा रहा है, किसी भी डिजाइन के होने से पहले विकास शुरू हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन अक्सर बाद में इसे फिर से काम करना पड़ता है।
+* व्यावसायिक दाब, जहां आवश्यक परिवर्तन पूर्ण होने से पहले व्यवसाय शीघ्र ही कुछ प्रारम्भ करने पर विचार करता है। और उन अधूरे परिवर्तनों को सम्मिलित करते हुए तकनीकी ऋण का निर्माण करता है।{{r|SuryanarayanaSamarthyam2014|p=4}}{{r|Sterling2010|p=22}}
-* व्यावसायिक दबाव, जहाँ व्यवसाय आवश्यक परिवर्तनों के पूर्ण होने से पहले ही कुछ जारी करने पर विचार करता है, उन अधूरे परिवर्तनों को शामिल करते हुए तकनीकी ऋण का निर्माण करता है।{{r|SuryanarayanaSamarthyam2014|p=4}}{{r|Sterling2010|p=22}}
+* प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अप्रत्यक्ष होते हैं। और निहितार्थों पर विचार किए बिना निर्णय लेते हैं।
-* प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अंधे होते हैं, और निहितार्थों पर विचार किए बिना निर्णय लेते हैं।
+* [[ युग्मन (कंप्यूटर प्रोग्रामिंग) |युग्मन (कंप्यूटर प्रोग्रामिंग)]] , जहां कार्य [[मॉड्यूलर प्रोग्रामिंग]] नहीं हैं, सॉफ्टवेयर इतना नम्य नहीं होता है कि वह व्यावसायिक आवश्यकताओ में परिवर्तन के अनुकूल हो सके।
-* [[ युग्मन (कंप्यूटर प्रोग्रामिंग) ]], जहां कार्य [[मॉड्यूलर प्रोग्रामिंग]] नहीं हैं, सॉफ्टवेयर इतना लचीला नहीं है कि वह व्यावसायिक जरूरतों में बदलाव के अनुकूल हो सके।
+* [[परीक्षण सूट]] का अभाव, जो त्वरित और जोखिम से पूर्ण [[बैंड-ऐड (कम्प्यूटिंग)]] बग निर्धारण को प्रोत्साहित करता है।
-* एक [[परीक्षण सूट]] का अभाव, जो त्वरित और जोखिम भरा [[बैंड-ऐड (कम्प्यूटिंग)]] | बैंड-ऐड बग फिक्स को प्रोत्साहित करता है।
 * सॉफ़्टवेयर दस्तावेज़ों का अभाव, जहाँ दस्तावेज़ों का समर्थन किए बिना कोड बनाया जाता है। दस्तावेज़ बनाने का कार्य ऋण का प्रतिनिधित्व करता है।<ref name="SuryanarayanaSamarthyam2014">{{cite book|author1=Girish Suryanarayana|author2=Ganesh Samarthyam|author3=Tushar Sharma|title=Refactoring for Software Design Smells: Managing Technical Debt|url=https://books.google.com/books?id=1SaOAwAAQBAJ&pg=PA3|date=11 November 2014|publisher=Elsevier Science|isbn=978-0-12-801646-6|page=3}}</ref>
-* सहयोग का अभाव, जहां ज्ञान को संगठन के आसपास साझा नहीं किया जाता है और व्यावसायिक दक्षता प्रभावित होती है, या जूनियर डेवलपर्स को ठीक से सलाह नहीं दी जाती है।
+* सहयोग का अभाव, जहां ज्ञान को संगठन के आसपास साझा नहीं किया जाता है और व्यावसायिक दक्षता प्रभावित होती है या जूनियर विकासक को ठीक से सलाह नहीं दी जाती है।
-* एक स्रोत आधार में परिवर्तनों को मर्ज करने के लिए आवश्यक कार्य के कारण कई शाखाओं पर समानांतर विकास तकनीकी ऋण अर्जित करता है। अलगाव में जितने अधिक परिवर्तन किए जाते हैं, उतना अधिक ऋण।
+* एक स्रोत आधार में परिवर्तनों को संयुक्त करने के लिए आवश्यक कार्य के कारण कई शाखाओं पर समानांतर विकास तकनीकी ऋण उपस्थित होता है। अंतर्राष्ट्रीय स्थिति में जितने अधिक परिवर्तन किए जाते हैं उतना अधिक ऋण होता है।
-* आस्थगित [[कोड रीफैक्टरिंग]]; जैसे-जैसे किसी परियोजना के लिए आवश्यकताएँ विकसित होती हैं, यह स्पष्ट हो सकता है कि कोड के भाग अक्षम या संपादित करने में कठिन हो गए हैं और भविष्य की आवश्यकताओं का समर्थन करने के लिए उन्हें फिर से तैयार किया जाना चाहिए। जितनी लंबी रिफैक्टरिंग में देरी होगी, और जितना अधिक कोड जोड़ा जाएगा, उतना ही बड़ा कर्ज होगा।{{r|Sterling2010|p=29}}
+* स्थगित [[कोड रीफैक्टरिंग|कोड पुनर्रचना]], जैसे-जैसे किसी परियोजना के लिए आवश्यकताएँ विकसित होती हैं वैसे ही यह स्पष्ट हो सकता है कि कोड के भाग अक्षम या संपादित करने में कठिन हो गए हैं और भविष्य की आवश्यकताओं का समर्थन करने के लिए उन्हें फिर से तैयार किया जाना चाहिए। जितनी लंबी पुनर्रचना में देरी होती है और जितना अधिक कोड जोड़ा जाता है उतना ही अधिक ऋण हो सकता है।{{r|Sterling2010|p=29}}
-* मानकों के संरेखण की कमी, जहां उद्योग मानक सुविधाओं, सॉफ्टवेयर ढांचे और प्रौद्योगिकियों की अनदेखी की जाती है। आखिरकार मानकों के साथ एकीकरण आ जाएगा और ऐसा करने में जल्द ही कम खर्च आएगा (विलंबित रीफैक्टरिंग के समान)।{{r|SuryanarayanaSamarthyam2014|p=7}}
+* मानकों के संरेखण की कमी, जहां उद्योग मानक सुविधाओं, सॉफ्टवेयर संरचना और प्रौद्योगिकियों को अस्वीकृत करते है। अंत मे मानकों के साथ एकीकरण आ सकता है और ऐसा करने में शीघ्र ही विलंबित पुनर्रचना के समान कम खर्च लग सकती है।{{r|SuryanarayanaSamarthyam2014|p=7}}
-* ज्ञान की कमी, जब डेवलपर को यह नहीं पता होता है कि सुरुचिपूर्ण कोड कैसे लिखना है।<ref name="Sterling2010">{{cite book|author=Chris Sterling|title=Managing Software Debt: Building for Inevitable Change (Adobe Reader)|url=https://books.google.com/books?id=LYQlOaRwpnEC&pg=PA17|date=10 December 2010|publisher=Addison-Wesley Professional|isbn=978-0-321-70055-1|page=17}}</ref>
+* ज्ञान की कमी, जब विकासक को यह नहीं पता होता है कि सहज कोड कैसे लिखना है।<ref name="Sterling2010">{{cite book|author=Chris Sterling|title=Managing Software Debt: Building for Inevitable Change (Adobe Reader)|url=https://books.google.com/books?id=LYQlOaRwpnEC&pg=PA17|date=10 December 2010|publisher=Addison-Wesley Professional|isbn=978-0-321-70055-1|page=17}}</ref>
-* स्वामित्व की कमी, जब आउटसोर्स किए गए सॉफ़्टवेयर प्रयासों के परिणामस्वरूप इन-हाउस इंजीनियरिंग को कोड रिफैक्टरिंग या [[कोड पुनर्लेखन]] आउटसोर्स कोड की आवश्यकता होती है।
+*अंतिम मिनट विनिर्देश परिवर्तन, इनमें एक परियोजना के समय प्रसारित होने की क्षमता है। लेकिन परिवर्तनों का दस्तावेजीकरण और परीक्षण करने के लिए अपर्याप्त समय या बजट है।
-* खराब तकनीकी नेतृत्व, जहां खराब तरीके से सोची गई कमानों को कमान की शृंखला सौंपी जाती है।
+* स्वामित्व की कमी, जब बाह्‌य स्रोत किए गए सॉफ़्टवेयर प्रयासों के परिणामस्वरूप घरेलू अभियांत्रिकी को कोड पुनर्रचना या [[कोड पुनर्लेखन]] बाह्‌य स्रोत कोड की आवश्यकता होती है।
-* अंतिम मिनट विनिर्देश परिवर्तन। इनमें एक परियोजना के दौरान रिसने की क्षमता है, लेकिन परिवर्तनों का दस्तावेजीकरण और परीक्षण करने के लिए अपर्याप्त समय या बजट है।
+* तुच्छ तकनीकी नेतृत्व, जहां तुच्छ तरीके से विचार किए गए प्रयासों को निर्धारित शृंखला के साथ प्रयुक्त किया जाता है।
-== सेवा या तकनीकी ऋण चुकाना ==
+== सेवा या तकनीकी ऋण भुगतान ==
-केनी रुबिन निम्नलिखित स्थिति श्रेणियों का उपयोग करता है:<ref name="Essential Scrum: Velocity">{{Citation
+केनी रुबिन निम्न स्थिति श्रेणियों का उपयोग करता है:<ref name="Essential Scrum: Velocity">{{Citation
   |date = 2013
   |title            = Essential Scrum. A Practical Guide to the Most Popular Agile Process
@@ Line 36: / Line 35: @@
   |page             = 155
   |isbn          = 978-0-13-704329-3}}</ref>
-* हुआ-तकनीकी ऋण-ऋण कि विकास दल अनजान था जब तक कि उत्पाद पर काम करने के सामान्य कार्य के दौरान इसका खुलासा नहीं हुआ। उदाहरण के लिए, टीम उत्पाद में एक नई सुविधा जोड़ रही है और ऐसा करने पर यह महसूस होता है कि किसी ऐसे व्यक्ति द्वारा कोड वर्षों पहले वर्क-अराउंड बनाया गया था जो लंबे समय से विदा हो चुका है।
+* तकनीकी ऋण पर हुआ ऋण से विकास समूह अनभिज्ञ था जब तक कि उत्पाद पर कार्य करने के सामान्य कार्य के समय इसका विकास नहीं हुआ। उदाहरण के लिए समूह उत्पाद में एक नई सुविधा जोड़ रही है और ऐसा करने पर यह प्रतीत होता है कि किसी ऐसे व्यक्ति द्वारा कोड वर्षों पहले कार्य के लिए बनाया गया था जो लंबे समय से समाप्त हो चुका है।
-* ज्ञात तकनीकी ऋण—ऋण जो विकास दल को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है।
+* ज्ञात तकनीकी ऋण, वह ऋण जो विकास समूह को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है।
-* लक्षित तकनीकी ऋण—ऋण जो ज्ञात है और विकास दल द्वारा सर्विसिंग के लिए लक्षित किया गया है।
+* लक्षित तकनीकी ऋण, वह ऋण जो ज्ञात है और विकास समूह द्वारा संरक्षण के लिए लक्षित किया गया है।
 == परिणाम ==
+"ब्याज भुगतान" आवश्यक स्थानीय संरक्षण और परियोजना के अन्य उपयोगकर्ताओं द्वारा संरक्षण की अनुपस्थिति दोनों के कारण होता है। प्रतिप्रवाह परियोजना में चल रहे विकास से भविष्य में "ऋण भुगतान" की लागत बढ़ सकती है।{{Clarify|Which upstream project?|date=October 2013}} केवल अपूर्ण कार्य को पूरा करके ऋण का भुगतान किया जा सकता है।{{Citation needed|date=May 2018}}
- ब्याज भुगतान आवश्यक स्थानीय रखरखाव और परियोजना के अन्य उपयोगकर्ताओं द्वारा रखरखाव की अनुपस्थिति दोनों के कारण होता है। [[अपस्ट्रीम (सॉफ्टवेयर विकास)]] परियोजना में चल रहे विकास से भविष्य में कर्ज चुकाने की लागत बढ़ सकती है।{{Clarify|Which upstream project?|date=October 2013}} अधूरे काम को पूरा करके ही कर्ज चुकाया जा सकता है।{{Citation needed|date=May 2018}}
+तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा की असफलता का एक प्रमुख कारण है।{{Citation needed|date=April 2013}} यह अनुमान लगाना कठिन है कि ऋण का भुगतान करने के लिए कितना कार्य आवश्यक है। प्रत्येक परिवर्तन के लिए जो प्रारम्भ किया गया है। वह परियोजना के लिए अपूर्ण कार्य की अनिश्चित राशि प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। पूर्वानुमेय प्रकाशन अनुक्रम के लिए एक विकास समुदाय को अपूर्ण की मात्रा को बनाए रखने के लिए कार्य की मात्रा को सीमित करना चाहिए जिससे कार्य (या कर्ज) प्रत्येक समय अपेक्षाकृत कम हो सकता है।{{Citation needed|date=May 2018}}
-तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा से चूकने का एक प्रमुख कारण है।{{Citation needed|date=April 2013}} ऋण का भुगतान करने के लिए वास्तव में कितना काम आवश्यक है, इसका अनुमान लगाना (परियोजना प्रबंधन) मुश्किल है। शुरू किए गए प्रत्येक परिवर्तन के लिए, अपूर्ण कार्य की एक अनिश्चित राशि परियोजना के लिए प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। अनुमानित रिलीज शेड्यूल रखने के लिए, एक विकास दल को कार्य की मात्रा को सीमित करना चाहिए ताकि राशि को बनाए रखा जा सके। अधूरा काम (या कर्ज) हर समय छोटा।{{Citation needed|date=May 2018}}
+यदि एक परियोजना पर पर्याप्त कार्य पूरा हो जाता है जो प्रस्तुत करने में बाधा उत्पन्न नहीं करता है, तो एक परियोजना प्रारम्भ की जाएगी जो अभी भी पर्याप्त मात्रा में तकनीकी ऋण वहन करती है। यदि यह सॉफ्टवेयर उत्पादन तक अभिगम्य होता है तो तकनीकी ऋण को संबोधित करने वाले किसी भी भविष्य की पुनर्रचना को प्रयुक्त करने का जोखिम प्रभावशाली रूप से बढ़ जाता है। यदि अनुबंधों में सेवा स्तरीय समझौते (एसएलए) सम्मिलित हैं तो उत्पादन कोड को संशोधित करने से वास्तविक वित्तीय हानि और संभवतः कानूनी परिणाम का जोखिम होता है। इस कारण से हम तकनीकी ऋण को उत्पादन तक ले जाने को लगभग इस प्रकार देख सकते हैं जैसे कि यह ब्याज दर में वृद्धि थी और केवल एक बार यह घटता है जब परिनियोजना को अस्वीकृत या सेवानिवृत्त कर दिया जाता है।
-यदि एक परियोजना पर पर्याप्त काम पूरा हो जाता है जो प्रस्तुत करने में बाधा उत्पन्न नहीं करता है, तो एक परियोजना जारी की जाएगी जो अभी भी पर्याप्त मात्रा में तकनीकी ऋण वहन करती है। यदि यह सॉफ्टवेयर उत्पादन तक पहुंचता है, तो तकनीकी ऋण को संबोधित करने वाले किसी भी भविष्य के रिफ्लेक्टर को लागू करने का जोखिम नाटकीय रूप से बढ़ जाता है। यदि अनुबंधों में सेवा-स्तरीय समझौते (SLA) शामिल हैं, तो उत्पादन कोड को संशोधित करने से आउटेज, वास्तविक वित्तीय नुकसान और संभवतः कानूनी नतीजों का जोखिम होता है। इस कारण से हम तकनीकी ऋण को उत्पादन तक ले जाने को लगभग इस तरह देख सकते हैं जैसे कि यह ब्याज दर में वृद्धि थी और केवल एक बार यह घटता है जब तैनाती को ठुकरा दिया जाता है और सेवानिवृत्त कर दिया जाता है।
+{{quotation |"एक विकसित कार्य के रूप में निरंतर परिवर्तन होता रहता है इसकी जटिलता, ह्रासित संरचना को दर्शाती है। जब तक इसे बनाए रखने या कम करने के लिए कार्य नहीं किया जाता है।"<ref>{{cite journal|last1=Lehman|first1=MM|title=Laws of Software Evolution Revisited|journal=EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology|date=1996|pages=108–124|isbn=9783540617716 |url=http://dl.acm.org/citation.cfm?id=681473|access-date=19 November 2014}}</ref> |[[मीर मैनी लेहमन]], 1980}}
-{{quotation |"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."<ref>{{cite journal|last1=Lehman|first1=MM|title=Laws of Software Evolution Revisited|journal=EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology|date=1996|pages=108–124|isbn=9783540617716 |url=http://dl.acm.org/citation.cfm?id=681473|access-date=19 November 2014}}</ref> |[[Meir Manny Lehman]], 1980}}
+जबकि [[ मीर मैनी लेहमन |मीर मैनी लेहमन]] के नियम ने पहले ही संकेत दिया था कि विकसित कार्य निरंतर उनकी जटिलता और ह्रासित संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए कार्य नहीं किया जाता है। [[वार्ड कनिंघम]] ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना किया था:
-जबकि [[ मीर मैनी लेहमन ]] के कानून ने पहले ही संकेत दिया था कि विकसित कार्यक्रम लगातार उनकी जटिलता और बिगड़ती संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए काम नहीं किया जाता है, [[वार्ड कनिंघम]] ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना की:
+{{quotation |"अपरिपक्व समुदाय पहली बार कोड ऋण में जाने जैसा होता है। एक छोटा सा ऋण विकास को तब तक गति देता है जब तक इसे पुनर्लेखन के साथ शीघ्र वापस भुगतान किया जाता है। इसमे जोखिम तब होता है जब ऋण भुगतान नहीं जाता है। पूर्णतः सही कोड पर बिताया गया प्रत्येक मिनट उस ऋण पर [[ब्याज]] के रूप में गिना जाता है। संपूर्ण इंजीनियरिंग संगठनों को एक असमेकित कार्यान्वयन [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग|वस्तु उन्मुख]] के ऋण भार के अंतर्गत स्थिर किया जा सकता है। "<ref name='oopsla92'>{{cite web|url=http://c2.com/doc/oopsla92.html|title=The WyCash Portfolio Management System|date=1992-03-26|access-date=2008-09-26|author=Ward Cunningham|author-link=Ward Cunningham}}</ref> |[[वार्ड कनिंघम]], 1992}}
-{{quotation |"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as [[interest]] on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, [[Object-oriented programming|object-oriented]] or otherwise."<ref name='oopsla92'>{{cite web|url=http://c2.com/doc/oopsla92.html|title=The WyCash Portfolio Management System|date=1992-03-26|access-date=2008-09-26|author=Ward Cunningham|author-link=Ward Cunningham}}</ref> |[[Ward Cunningham]], 1992}}
+[[जोशुआ केरिवेस्की]] वास्तु ने अपने 2004 के लेख में पुनर्रचना पैटर्न कमी से संबद्ध लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत किया है। जिसे वह "डिजाइन ऋण" के रूप में वर्णित करते है।<ref name="rtp">{{cite book|isbn=978-0-321-21335-8|first=Joshua|last=Kerievsky|title=पैटर्न के लिए रिफैक्टरिंग|year=2004}}</ref>
-अपने 2004 के पाठ में, रिफैक्टरिंग टू पैटर्न्स, [[जोशुआ केरिवेस्की]] वास्तुशिल्प लापरवाही से जुड़ी लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत करता है, जिसे वह डिजाइन ऋण के रूप में वर्णित करता है।<ref name="rtp">{{cite book|isbn=978-0-321-21335-8|first=Joshua|last=Kerievsky|title=पैटर्न के लिए रिफैक्टरिंग|year=2004}}</ref>
+जिन गतिविधियों को स्थगित किया जा सकता है उनमें दस्तावेज़ीकरण, [[ परीक्षण स्वचालन |परीक्षण स्वचालन]], टीओडीओ टिप्पणियों पर ध्यान देना, संकलक और स्थैतिक कोड विश्लेषण चेतावनियों का सामना करना सम्मिलित है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान सम्मिलित है। जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।{{Citation needed|date=May 2018}}
-जिन गतिविधियों को स्थगित किया जा सकता है उनमें [[प्रलेखन]], [[ परीक्षण स्वचालन ]] लिखना, टिप्पणी (कंप्यूटर प्रोग्रामिंग)#टैग पर ध्यान देना और संकलक और स्थैतिक कोड विश्लेषण चेतावनियों से निपटना शामिल है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान शामिल है जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।{{Citation needed|date=May 2018}}
-में PHP के विकास के बारे में लिखते हुए, [[जुनादे अली]] ने कहा:
+में पीएचपी के विकास के विषय में लिखते हुए, [[जुनादे अली]] ने कहा कि:
-{{quotation|The cost of never paying down this technical debt is clear; eventually the cost to deliver functionality will become so slow that it is easy for a well-designed competitive software product to overtake the badly-designed software in terms of features. In my experience, badly designed software can also lead to a more stressed engineering workforce, in turn leading higher staff churn (which in turn affects costs and productivity when delivering features). Additionally, due to the complexity in a given codebase, the ability to accurately estimate work will also disappear. In cases where development agencies charge on a feature-to-feature basis, the profit margin for delivering code will eventually deteriorate.|[[Junade Ali]] writes in ''Mastering PHP Design Patterns''<ref>{{cite book|last1=Ali|first1=Junade|title=Mastering PHP Design Patterns {{!}} PACKT Books|date=September 2016|publisher=Packt Publishing Limited|location=Birmingham, England, UK|isbn=978-1-78588-713-0|page=11|edition=1|url=https://www.packtpub.com/application-development/mastering-php-design-patterns|access-date=11 December 2017|language=en}}</ref>}}
+{{quotation|इस तकनीकी ऋण को कभी न भुगतान करने की कीमत स्पष्ट है अंततः कार्यक्षमता प्रदान करने की लागत इतनी धीमी हो सकती है कि एक अच्छी तरह से डिज़ाइन किए गए प्रतिस्पर्धी सॉफ़्टवेयर उत्पाद के लिए सुविधाओं कि स्थिति में डिज़ाइन किए गए सॉफ़्टवेयर से आगे निकलना आसान हो सकता है मेरे अनुभव में, अपेक्षाकृत असहज प्रकार से डिज़ाइन किया गया सॉफ़्टवेयर भी एक अधिक तनावग्रस्त इंजीनियरिंग कार्यबल का कारण बन सकता है। जिसके परिणामस्वरूप उच्च कर्मचारी मंथन होता है जो सुविधाओं को वितरित करते समय लागत और उत्पादकता को प्रभावित करता है। इसके अतिरिक्त किसी दिए गए कोडबेस में जटिलता के कारण कार्य का शुद्ध अनुमान लगाने की क्षमता भी लुप्त हो सकती है। ऐसी स्थिति में जहां विकास संस्थाए विशिष्ट गुण के आधार पर चार्ज करती हैं। जिससे कोड अभिगम्य करने के लिए लाभ दर अंततः नष्ट हो सकती है।|[[जुनादे अली]], [[''प्राप्त पीएचपी डिजाइन पैटर्न'']]<ref>{{cite book|last1=Ali|first1=Junade|title=Mastering PHP Design Patterns {{!}} PACKT Books|date=September 2016|publisher=Packt Publishing Limited|location=Birmingham, England, UK|isbn=978-1-78588-713-0|page=11|edition=1|url=https://www.packtpub.com/application-development/mastering-php-design-patterns|access-date=11 December 2017|language=en}}</ref>}}
-[[ग्रेडी बूच]] ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर-गहन प्रणालियों के विकास के समान हैं और रिफैक्टरिंग की कमी कैसे तकनीकी ऋण का कारण बन सकती है।
+[[ग्रेडी बूच]] ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर सघन प्रणालियों के विकास के समान हैं और पुनर्रचना की कमी कैसे तकनीकी ऋण का कारण बन सकती है।
-{{quotation |"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."<ref name="Girish 2014"/> |[[Grady Booch]], 2014}}
+{{quotation |तकनीकी ऋण की अवधारणा उन वस्तुओ को समझने के लिए केंद्रीय है जो प्रणाली पर भारित हैं क्योंकि ये प्रायः करती है कि प्रणाली कहां, कैसे और क्यों तनावग्रस्त है। कई शहरों में आधारिक संरचना के संरक्षण में प्रायः देरी होती है और बड़े परिवर्तन के अतिरिक्त वृद्धिशील परिवर्तन किए जाते हैं। तो यह फिर से सॉफ्टवेयर गहन प्रणालियों में है। उपयोगकर्ताओं को अपेक्षाकृत जटिलता, विलंबित सुधार और अपर्याप्त वृद्धिशील परिवर्तन के परिणाम का सामना करना पड़ता हैं। विकासक जो इस प्रकार की प्रणाली को विकसित करते हैं। वे कभी भी गुणवत्ता कोड लिखने में सक्षम नहीं होने के संकेत और चिन्ह को पीड़ित करते हैं क्योंकि वे सदैव अभिग्रहण का प्रयास करते हैं।<ref name="Girish 2014"/> |[[ग्रेडी बूच]], 2014}}
-[[खुला स्रोत सॉफ्टवेयर]] में, अपस्ट्रीम प्रोजेक्ट में स्थानीय परिवर्तन भेजना स्थगित करना तकनीकी ऋण का एक रूप है।{{Citation needed|date=May 2018}}
+मुक्त स्रोत सॉफ़्टवेयर में धारावाहिक परियोजना के स्थानीय परिवर्तन को भेजना या स्थगित करना तकनीकी ऋण का एक रूप है।{{Citation needed|date=May 2018}}
 == यह भी देखें ==
-* [[कोड गंध]] (अवर कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते हैं)
+* [[कोड गंध]] - तुच्छ कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते हैं।
 * [[मिट्टी का बड़ा गोला]]
 * [[बस कारक]]
 * [[प्रतिबद्धता की वृद्धि]]
-* [[मनुवाद]]
+* [[मनुवाद|परिपक्वता]]
 * [[अति अभियांत्रिकी]]
-* [[शॉटगन सर्जरी]]
+* [[शॉटगन सर्जरी|शॉटगन चिकित्सा]]
 * सॉफ्टवेयर एन्ट्रापी
-* [[सॉफ्टवेयर सड़ांध]]
+* [[सॉफ्टवेयर सड़ांध|सॉफ्टवेयर अपक्षय]]
 * [[स्पेगेटी कोड]]
-* [[ शुरू ]]
+* [[ शुरू |एसक्यूएएलई]]
 * [[विफल लागत]]
-* टिप्पणी (कंप्यूटर प्रोग्रामिंग)#टैग|TODO, FIXME, XXX
+* टीओडीओ, फिक्समे, एक्सएक्सएक्स (प्रोग्रामिंग भाषा)
 ==संदर्भ==
@@ Line 99: / Line 98: @@
 * [https://gauravtiwari.org/2016/12/10/technical-debts-basics/ Technical debts: Everything you need to know]
 * [https://deepsource.io/blog/what-is-technical-debt/ What is technical debt?] from DeepSource blog
-[[Category: रूपकों]] [[Category: सॉफ़्टवेयर वास्तुशिल्प]] [[Category: सॉफ्टवेयर इंजीनियरिंग शब्दावली]] [[Category: सॉफ्टवेयर की रखरखाव]]
+[[Category:All articles with unsourced statements]]
+[[Category:Articles with unsourced statements from April 2013]]
-[[Category: Machine Translated Page]]
+[[Category:Articles with unsourced statements from May 2018]]
+[[Category:CS1 English-language sources (en)]]
 [[Category:Created On 10/05/2023]]
+[[Category:Lua-based templates]]
+[[Category:Machine Translated Page]]
+[[Category:Pages with script errors]]
+[[Category:Templates Vigyan Ready]]
+[[Category:Templates that add a tracking category]]
+[[Category:Templates that generate short descriptions]]
+[[Category:Templates using TemplateData]]
+[[Category:Wikipedia articles needing clarification from October 2013]]
+[[Category:रूपकों]]
+[[Category:सॉफ़्टवेयर वास्तुशिल्प]]
+[[Category:सॉफ्टवेयर इंजीनियरिंग शब्दावली]]
+[[Category:सॉफ्टवेयर की रखरखाव]]

Anonymous

Search

तकनीकी ऋण: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 17:07, 25 May 2023

Contents

कारण

सेवा या तकनीकी ऋण भुगतान

परिणाम

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

तकनीकी ऋण: Difference between revisions

Latest revision as of 17:07, 25 May 2023

कारण

सेवा या तकनीकी ऋण भुगतान

परिणाम

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories