तकनीकी ऋण
सॉफ़्टवेयर विकास में तकनीकी ऋण को डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है।[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 में पीएचपी के विकास के विषय में लिखते हुए, जुनादे अली ने कहा कि:
इस तकनीकी ऋण को कभी न भुगतान करने की कीमत स्पष्ट है अंततः कार्यक्षमता प्रदान करने की लागत इतनी धीमी हो सकती है कि एक अच्छी तरह से डिज़ाइन किए गए प्रतिस्पर्धी सॉफ़्टवेयर उत्पाद के लिए सुविधाओं कि स्थिति में डिज़ाइन किए गए सॉफ़्टवेयर से आगे निकलना आसान हो सकता है मेरे अनुभव में, अपेक्षाकृत असहज प्रकार से डिज़ाइन किया गया सॉफ़्टवेयर भी एक अधिक तनावग्रस्त इंजीनियरिंग कार्यबल का कारण बन सकता है। जिसके परिणामस्वरूप उच्च कर्मचारी मंथन होता है जो सुविधाओं को वितरित करते समय लागत और उत्पादकता को प्रभावित करता है। इसके अतिरिक्त किसी दिए गए कोडबेस में जटिलता के कारण कार्य का शुद्ध अनुमान लगाने की क्षमता भी लुप्त हो सकती है। ऐसी स्थिति में जहां विकास संस्थाए विशिष्ट गुण के आधार पर चार्ज करती हैं। जिससे कोड अभिगम्य करने के लिए लाभ दर अंततः नष्ट हो सकती है।
ग्रेडी बूच ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर सघन प्रणालियों के विकास के समान हैं और पुनर्रचना की कमी कैसे तकनीकी ऋण का कारण बन सकती है।
तकनीकी ऋण की अवधारणा उन वस्तुओ को समझने के लिए केंद्रीय है जो प्रणाली पर भारित हैं क्योंकि ये प्रायः करती है कि प्रणाली कहां, कैसे और क्यों तनावग्रस्त है। कई शहरों में आधारिक संरचना के संरक्षण में प्रायः देरी होती है और बड़े परिवर्तन के अतिरिक्त वृद्धिशील परिवर्तन किए जाते हैं। तो यह फिर से सॉफ्टवेयर गहन प्रणालियों में है। उपयोगकर्ताओं को अपेक्षाकृत जटिलता, विलंबित सुधार और अपर्याप्त वृद्धिशील परिवर्तन के परिणाम का सामना करना पड़ता हैं। विकासक जो इस प्रकार की प्रणाली को विकसित करते हैं। वे कभी भी गुणवत्ता कोड लिखने में सक्षम नहीं होने के संकेत और चिन्ह को पीड़ित करते हैं क्योंकि वे सदैव अभिग्रहण का प्रयास करते हैं।[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
