3.7 सॉफ़्टवेयर अनुरक्षण

अवलोकन और प्रेरणा

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

अनुरक्षण को लगातार कम आँका और कम महत्व दिया जाता है, और यह गलती महँगी पड़ती है। दशकों में एक के बाद एक अध्ययन यह दिखाते हैं कि अनुरक्षण कुल आजीवन सॉफ़्टवेयर लागत के आधे से कहीं ज़्यादा हिस्से पर बैठता है, जिसे आमतौर पर दीर्घजीवी सिस्टम के लिए 60 से 90 प्रतिशत की सीमा में बताया जाता है। फिर भी संगठन शुरुआती निर्माण की योजना बनाते हैं, उसके लिए बजट रखते हैं, स्टाफ़ लगाते हैं, और उसे ऐसे मनाते हैं जैसे वही पूरा उपक्रम हो। फिर वे उसके बाद की हर चीज़ को एक बाद के विचार की तरह मानते हैं, जिसे सिकुड़ते हुए बजट से वित्तपोषित किया जाता है और जो भी उपलब्ध हो उसे सौंप दिया जाता है। नतीजा पूर्वानुमेय है: भंगुर सिस्टम, हतोत्साहित अनुरक्षक, बढ़ती हुई बदलाव की लागत, और अंततः एक ऐसा संकट जिसे “लेगेसी समस्या” (अध्याय 3.6) करार दे दिया जाता है, जबकि वह वास्तव में शुरू से ही एक अप्रबंधित-अनुरक्षण की समस्या थी।

यह अध्याय SWEBOK (सॉफ़्टवेयर इंजीनियरिंग बॉडी ऑफ़ नॉलेज) के सॉफ़्टवेयर मेंटेनेंस नॉलेज एरिया और ISO/IEC 14764 का अनुसरण करता है। यह अनुरक्षण के मूल सिद्धांतों और चार मान्यता-प्राप्त श्रेणियों को शामिल करता है; उन मुख्य मुद्दों को जो अनुरक्षण को कठिन बनाते हैं, जिनमें लागत, स्टाफ़िंग, और मनोबल शामिल हैं; अनुरक्षण प्रक्रिया को; प्रोग्राम कॉम्प्रिहेंशन, री-इंजीनियरिंग, और रीफ़ैक्टरिंग की मुख्य तकनीकों को; अनुरक्षण लागत का अनुमान कैसे लगाया जाए; और (इस अध्याय का सबसे उच्च-लाभ वाला विचार) शुरू से ही अनुरक्षणीयता (maintainability) के लिए कैसे डिज़ाइन किया जाए। केंद्रीय मान्यता यह है कि अनुरक्षण कोई गौण गतिविधि नहीं है जो इंजीनियरिंग के बाद आती है। यह सॉफ़्टवेयर इंजीनियरिंग का सबसे बड़ा हिस्सा है, और इसे उसी तरह योजनाबद्ध, संसाधित, और सम्मानित किया जाना चाहिए।

मुख्य सिद्धांत

• अनुरक्षण जीवनचक्र का बहुमत है, कोई उपसंहार (epilogue) नहीं। इसके लिए पहले दिन से ही योजना बनाएँ और बजट रखें; इसकी लागत निर्माण से ज़्यादा होगी।
• चारों श्रेणियाँ अलग-अलग काम हैं। करेक्टिव, अडैप्टिव, परफ़ेक्टिव, और प्रिवेंटिव अनुरक्षण के प्रेरक और लय (cadence) अलग-अलग होते हैं; अधिकांश प्रयास बग-फ़िक्सिंग नहीं होता।
• आप उसे नहीं बदल सकते जिसे आप समझते नहीं। प्रोग्राम कॉम्प्रिहेंशन अनुरक्षण में सबसे बड़ी अकेली गतिविधि है; कोड और उसके इतिहास को सुपाठ्य (legible) बनाएँ।
• अनुरक्षणीयता (maintainability) एक डिज़ाइन गुण है। भविष्य के बदलाव की लागत बड़े पैमाने पर निर्माण के दौरान लिए गए निर्णयों से तय होती है; इसके लिए सोच-समझकर डिज़ाइन करें।
• छोटा, सुरक्षित, निरंतर बदलाव, टाले गए बड़े बदलाव से बेहतर है। एक टेस्ट सेफ़्टी नेट के तहत क्रमिक रूप से रीफ़ैक्टर और आधुनिकीकरण करें, न कि एक बदलाव ऋण (change debt) जमा होने दें।
• सॉफ़्टवेयर तब भी पुराना होता है जब वह स्थिर बैठा रहता है। वातावरण बदलता रहता है (डिपेंडेंसी, प्लेटफ़ॉर्म, नियमन), इसलिए एक स्थिर सिस्टम चुपचाप सड़ता रहता है; प्रिवेंटिव अनुरक्षण असली काम है।
• अनुरक्षकों को प्रथम-श्रेणी दर्जा मिलना चाहिए। अनुरक्षण टीमों का मनोबल, ज्ञान प्रतिधारण (knowledge retention), और स्टाफ़िंग सीधे दीर्घकालिक लागत और जोखिम तय करते हैं।

सिफारिशें

अनुरक्षण की चार श्रेणियों में अंतर करें और सभी के लिए स्टाफ़ रखें

ISO/IEC 14764 और SWEBOK चार श्रेणियों को मान्यता देते हैं, और इन्हें आपस में गड्डमड्ड करना एक आम योजना-त्रुटि है। करेक्टिव अनुरक्षण संचालन में मिले दोषों को ठीक करता है। अडैप्टिव अनुरक्षण सॉफ़्टवेयर को उसके वातावरण के बदलने पर भी काम करते रहने देता है: नए ऑपरेटिंग सिस्टम, ब्राउज़र, डिपेंडेंसी, हार्डवेयर, नियमन, या इंटरफ़ेसिंग सिस्टम। परफ़ेक्टिव अनुरक्षण उपयोगकर्ताओं और अनुरक्षकों के लिए सॉफ़्टवेयर को बेहतर बनाता है, नई सुविधाओं, बेहतर परफॉर्मेंस, बेहतर उपयोगिता (usability), और बढ़ी हुई अनुरक्षणीयता के ज़रिए। प्रिवेंटिव अनुरक्षण अव्यक्त (latent) दोषों को ठीक करता है और भविष्य के जोखिम को उसके प्रकट होने से पहले ही घटाता है, नाज़ुक क्षेत्रों को हार्डन करके, साफ़ करके, और आधुनिकीकृत करके। एक उपयोगी आगे का विभाजन करेक्टिव और प्रिवेंटिव को करेक्शन (दोषों से निपटना) और अडैप्टिव व परफ़ेक्टिव को एन्हांसमेंट (नई आवश्यकताओं से निपटना) के रूप में समूहित करता है। महत्वपूर्ण बात यह है कि अनुभवजन्य (empirical) अध्ययन लगातार यह पाते हैं कि अधिकांश अनुरक्षण करेक्टिव नहीं होता; एन्हांसमेंट और अडैप्टेशन ही हावी रहते हैं। तदनुसार बजट और स्टाफ़ तय करें, और यह ट्रैक करें कि आपका प्रयास वास्तव में किस श्रेणी में आता है ताकि आप इसे प्रबंधित कर सकें।

प्रोग्राम कॉम्प्रिहेंशन में निवेश करें

अनुरक्षण में सबसे बड़ी अकेली गतिविधि है मौजूदा सिस्टम को इतनी अच्छी तरह समझना कि उसे सुरक्षित रूप से बदला जा सके। अनुरक्षक आमतौर पर कोड को बदलने से ज़्यादा समय उसे पढ़ने और उस पर तर्क करने में बिताते हैं। इसे जान-बूझकर सस्ता बनाएँ। दस्तावेज़ीकरण को कोड के करीब और अद्यतन (current) रखें (अध्याय 2.7)। आर्किटेक्चर डिसीज़न रिकॉर्ड (अध्याय 1.6) और स्वच्छ कमिट इतिहास (अध्याय 2.6) के ज़रिए निर्णय इतिहास को सहेजें। अपरिचित क्षेत्र का नक्शा बनाने के लिए स्टैटिक एनालिसिस, डिपेंडेंसी ग्राफ़, और कोड नेविगेशन टूलिंग का उपयोग करें। कैरेक्टराइज़ेशन टेस्ट (ऐसे टेस्ट जो वर्तमान व्यवहार को, उसकी विचित्रताओं (quirks) सहित, स्थिर कर देते हैं) मौन (tacit) समझ को एक्ज़िक्यूटेबल, टिकाऊ ज्ञान में बदल देते हैं। जब समझ महँगी होती है, तो हर बदलाव धीमा और जोखिम भरा होता है। जब यह सस्ती होती है, तो अनुरक्षण नियमित काम बन जाता है।

एक टेस्ट सेफ़्टी नेट के तहत निरंतर रीफ़ैक्टर करें

रीफ़ैक्टरिंग कोड की अनुशासित पुनर्संरचना है जो उसके बाहरी व्यवहार को बदले बिना उसकी आंतरिक गुणवत्ता को बेहतर बनाती है। निरंतर और छोटे-छोटे कदमों में की जाने पर, यह जटिलता की ओर स्वाभाविक बहाव का प्रतिकार करती है और बदलाव की लागत को बढ़ने के बजाय स्थिर रखती है। इसकी गैर-परक्राम्य (non-negotiable) पूर्व-शर्त एक विश्वसनीय स्वचालित टेस्ट सूट (अध्याय 2.4) है। इसके बिना, “रीफ़ैक्टरिंग” सिर्फ़ जोखिम भरी पुनर्लेखन (rewriting) है। रीफ़ैक्टरिंग को रोज़मर्रा के काम में शामिल करें: हर मॉड्यूल को उससे थोड़ा साफ़ छोड़ें जितना आपको मिला था, बजाय इसे दुर्लभ, बड़ी, खतरनाक सफ़ाई के लिए बचाकर रखने के। यह व्यवहार में प्रिवेंटिव अनुरक्षण है, और यह सबसे सस्ता अनुरक्षण है जो मौजूद है।

जब क्रमिक बदलाव अब पर्याप्त न रहे, तब री-इंजीनियर करें

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

एक परिभाषित अनुरक्षण प्रक्रिया चलाएँ

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

अनुरक्षण लागत का स्पष्ट रूप से अनुमान लगाएँ और उसे वित्तपोषित करें

अनुरक्षण को मुफ़्त मानकर मत चलिए, या बिल्ड बजट के भीतर की एक शोर (noise) मानकर। इसका अनुमान लगाइए। आम तरीकों में शामिल हैं: मेंटेनेंस-एफ़र्ट रेश्यो (यह व्यापक रूप से प्रयुक्त अंगूठे का नियम कि वार्षिक अनुरक्षण मूल विकास लागत के लगभग 15 से 25 प्रतिशत के आसपास चलता है, हालाँकि दीर्घजीवी महत्वपूर्ण सिस्टम अपने जीवनकाल में इससे कहीं ज़्यादा जमा कर लेते हैं), COCOMO II (कंस्ट्रक्टिव कॉस्ट मॉडल) जैसे पैरामीट्रिक मॉडल अपने मेंटेनेंस व रीयूज़ एक्सटेंशन के साथ, और दोष दरों, बदलाव मात्रा, और बदलाव लागत के अपने ऐतिहासिक डेटा से मेट्रिक्स-संचालित पूर्वानुमान। इन अनुमानों को टोटल-कॉस्ट-ऑफ़-ओनरशिप विश्लेषण और अध्याय 10.10 में चर्चित अर्थशास्त्र में फ़ीड करें। किसी सिस्टम की खरीद कीमत या बिल्ड लागत एक डाउन पेमेंट है। मॉर्टगेज अनुरक्षण है, और इसे हर व्यावसायिक मामले (business case) में दिखना चाहिए।

शुरू से ही अनुरक्षणीयता के लिए डिज़ाइन करें

अनुरक्षण लागत पर सबसे ज़्यादा प्रभाव अनुरक्षण शुरू होने से पहले ही डाला जाता है। अनुरक्षणीयता (ISO/IEC 25010 की शब्दावली में विश्लेषणीयता, संशोधनीयता, टेस्ट करने योग्यता, और मॉड्युलैरिटी) एक डिज़ाइन गुणवत्ता है जो एक स्पष्ट आवश्यकता होनी चाहिए, कोई सुखद संयोग नहीं। मॉड्यूलर, ढीले-युग्मित (loosely coupled), उच्च-सामंजस्य (high-cohesion) डिज़ाइन (अध्याय 2.2); स्पष्ट इंटरफ़ेस और चिंताओं का पृथक्करण (separation of concerns); मज़बूत स्वचालित टेस्ट; सुपाठ्य कोड और अद्यतन दस्तावेज़ीकरण; और समृद्ध ऑब्ज़र्वेबिलिटी को प्राथमिकता दें ताकि ऑपरेटर और अनुरक्षक देख सकें कि सिस्टम क्या कर रहा है (भाग 9)। इनमें से हर निर्णय अभी थोड़ा ज़्यादा प्रयास करके उन दशकों में बड़ी, संचयी (compounding) बचत का व्यापार करता है जिनमें कोई सिस्टम वाकई जीवित रहेगा। अनुरक्षणीयता के लिए बनाना पूरे जीवनचक्र में सबसे ज़्यादा रिटर्न देने वाला निवेश है।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान
निरंतर रीफ़ैक्टरिंग / प्रिवेंटिव अनुरक्षण	बदलाव की लागत को स्थिर रखता है, जोखिम घटाता है, उच्च ROI	कोई दृश्य नई सुविधा नहीं देने वाला सतत प्रयास; मज़बूत टेस्ट चाहिए
अनुरक्षण को टालना (“लाइट्स ऑन रखना”)	इस तिमाही में सबसे सस्ता; सुविधाओं के लिए क्षमता मुक्त करता है	बदलाव ऋण बढ़ता जाता है; अंततः संकट और महँगी मजबूर कार्रवाई
किसी बिगड़े हुए घटक की री-इंजीनियरिंग	अनुरक्षणीयता बहाल करती है और उपयोगी जीवन बढ़ाती है	महत्वपूर्ण प्रयास और जोखिम; व्यवहार को सावधानी से बनाए रखना होगा
शुरू से ही अनुरक्षणीयता के लिए डिज़ाइन करना	संचयी आजीवन बचत; हर भविष्य का बदलाव आसान	अधिक शुरुआती लागत और अनुशासन; फ़ायदे टले हुए और कम दिखने वाले होते हैं

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आपके बजट में अनुरक्षण के आँकड़े का मालिक कौन है, और क्या यह एक प्रथम-श्रेणी लाइन है या बिल्ड ने जो खर्च नहीं किया उससे बचा हुआ एक अवशेष (residual)? अनुरक्षण आजीवन लागत का बहुमत है, दीर्घजीवी सिस्टम के लिए आमतौर पर 60 से 90 प्रतिशत, फिर भी इसे नियमित रूप से एक बाद के विचार की तरह वित्तपोषित किया जाता है और जो भी खाली हो उसे स्टाफ़ के रूप में लगा दिया जाता है। जब बजट अवशेष होता है, तो प्रिवेंटिव काम सबसे पहले काटा जाता है, बदलाव ऋण बढ़ता जाता है, और एक पूर्वानुमेय “लेगेसी संकट” की ओर फिसलन शुरू हो जाती है। एक वास्तविक अनुमान (एक मेंटेनेंस-एफ़र्ट रेश्यो, एक पैरामीट्रिक मॉडल, या आपका अपना ऐतिहासिक बदलाव-लागत डेटा) लाएँ और उस व्यक्ति का नाम बताएँ जो सिस्टम के पूरे जीवन में इसे वित्तपोषित करने के लिए जवाबदेह है। समाधान यह है कि अनुरक्षण को हर व्यावसायिक मामले में स्पष्ट रूप से बजट किया जाए, उसी तरह जैसे मॉर्टगेज खरीद कीमत के साथ बैठता है। जो नेतृत्व केवल लॉन्च मनाता है, वह उस चरण को कम-वित्तपोषित करता रहेगा जहाँ वास्तव में अधिकांश धन और जोखिम रहते हैं।

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

3. किसी सिस्टम को रिटायर करने की आपकी क्या योजना है, और आपने आख़िरी बार वाकई कब किसी को डीकमिशन किया था? रिटायरमेंट अनुरक्षण प्रक्रिया का एक स्पष्ट हिस्सा है (डेटा माइग्रेशन, उपयोगकर्ता कटओवर, रिकॉर्ड संरक्षण, सुरक्षित शटडाउन), फिर भी संगठन मृत और अनावश्यक (redundant) सिस्टम को वर्षों तक ढोते रहते हैं क्योंकि डीकमिशनिंग न तो आकर्षक है और न ही बजट में है। हर ज़ॉम्बी सिस्टम अभी भी लाइसेंस, सुरक्षा पैचिंग, एकीकरण सतह (integration surface), और उन लोगों का ध्यान खपत करता है जो कहीं और होते तो बेहतर होता। एक इन्वेंट्री लाएँ और उन सिस्टम को फ़्लैग करें जिनके कोई सक्रिय उपयोगकर्ता नहीं हैं या जिनकी पूरी प्रतिस्थापन (replacement) पहले से ही लाइव है, फिर उनके शटडाउन की योजना किसी भी अन्य काम की तरह बनाएँ: डेटा माइग्रेट करें, जो क़ानून आवश्यक करे उसे सहेजें, और पुष्टि करें कि अब कुछ भी उन पर निर्भर नहीं है। विशेष रूप से सरकार में, रिकॉर्ड-प्रतिधारण क़ानून यह तय करता है कि आप कैसे रिटायर करते हैं, इसलिए अनुपालन (compliance) को जल्दी शामिल करें। ट्रैक करने लायक एक परिपक्वता संकेत: आपके संगठन ने आख़िरी बार जान-बूझकर कब कुछ बंद किया था?

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

5. आपके अनुरक्षण काम में वास्तव में स्टाफ़ कौन है, और क्या इसका दर्जा व मनोबल इसके महत्व से मेल खाते हैं? अनुरक्षण आजीवन लागत का बहुमत है और मौजूद सबसे कठिन इंजीनियरिंग है, ऐसे सिस्टम को सुरक्षित रूप से बदलना जिन्हें आपने नहीं बनाया और जिन्हें आप शायद पूरी तरह नहीं समझते, फिर भी इसे नियमित रूप से सबसे कम अनुभवी लोगों को सौंप दिया जाता है और निम्न-दर्जे वाली “लाइट्स ऑन रखने” की तरह पेश किया जाता है। यह संकेत क्षयकारी (corrosive) है: आपके सबसे अच्छे इंजीनियर उस काम से बचते हैं, ज्ञान केंद्रित होकर फिर दरवाज़े से बाहर चला जाता है, और बदलाव की लागत बढ़ती रहती है जबकि कोई देख नहीं रहा होता। इसका सबूत लाएँ: आपके सबसे दीर्घजीवी सिस्टम का अनुरक्षण कौन करता है इसकी वरिष्ठता प्रोफ़ाइल, आपका एट्रिशन और ज्ञान-प्रतिधारण डेटा, और यह ईमानदार आकलन कि क्या आपके संगठन में अनुरक्षण एक करियर डेड-एंड है या एक सम्मानित विशेषज्ञता। तनाव वास्तविक है, क्योंकि महत्वाकांक्षी इंजीनियर नई चीज़ें बनाना चाहते हैं और नेता लॉन्च मनाना चाहते हैं, इसलिए अनुरक्षण का सम्मान करने के लिए सोच-समझकर संरचना चाहिए। एक बड़ी एंटरप्राइज़ या सार्वजनिक निकाय के लिए जो दशकों तक नियामक और वित्तीय जोखिम वहन करने वाले सिस्टम चलाता है, अनुरक्षण में सम्मानित वरिष्ठ इंजीनियरों को स्टाफ़ करना एक जोखिम-प्रबंधन निर्णय है, और अनुरक्षण को सज़ा की पोस्टिंग बनने देना ही वह तरीका है जिससे आप अगला लेगेसी संकट गढ़ते हैं।

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

क्षेत्रीय दृष्टिकोण

स्टार्टअप। मुट्ठी भर इंजीनियरों और कम रनवे के साथ, आप एक भारी-भरकम अनुरक्षण प्रक्रिया का खर्च नहीं उठा सकते, लेकिन आप ऐसा कोडबेस भी वहन नहीं कर सकते जिसे कोई छूना नहीं चाहता। हर चक्र का एक छोटा स्थायी हिस्सा (लगभग पाँच में से एक दिन) प्रिवेंटिव काम के लिए निकालें: डिपेंडेंसी पैच करें, छोटे दोषों को बढ़ने से पहले साफ़ करें, और जिन कोनों से आप पहले से डरते हैं उन्हें अपने पास मौजूद जो भी टेस्ट हों उनके तहत रीफ़ैक्टर करें। लक्ष्य यह है कि जब आप पिवट करें तब भी कोड को बदलना सस्ता बना रहे, ताकि आप कभी बीस इंजीनियरों तक पहुँचकर टाले हुए अनुरक्षण को “लेगेसी समस्या” समझने की गलती न करें।

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

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

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

उदाहरण

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

एंटरप्राइज़। एक वैश्विक बैंक एक पेमेंट्स प्लेटफ़ॉर्म चलाता है जो पंद्रह वर्षों से प्रोडक्शन में है। वह अनुरक्षण को एक अवशिष्ट बजट लाइन के बजाय एक स्थायी, प्रथम-श्रेणी कार्यक्रम के रूप में वित्तपोषित करता है। काम को चार श्रेणियों में ट्राइएज किया जाता है: अडैप्टिव बदलावों की एक स्थिर धारा नए नियमनों और पार्टनर-बैंक इंटरफ़ेस अपडेट को ट्रैक करती है, परफ़ेक्टिव काम सुविधाएँ जोड़ता है और थ्रूपुट सुधारता है, करेक्टिव काम सख़्त सर्विस-लेवल एग्रीमेंट (SLA) के मुक़ाबले दोषों को साफ़ करता है, और एक स्थायी प्रिवेंटिव आबंटन (टीम की क्षमता का लगभग पाँचवाँ हिस्सा) एक व्यापक टेस्ट सूट के तहत निरंतर रीफ़ैक्टरिंग के ज़रिए जटिलता को कम करता है। टीम चेंज लीड टाइम और चेंज फ़ेल्योर रेट मापती है, और किसी मॉड्यूल के बोझ बनने से पहले उसे री-इंजीनियर करने की शुरुआती चेतावनी के रूप में बढ़ती हुई बदलाव-की-लागत को मानती है। अनुरक्षक वरिष्ठ, प्रतिष्ठित इंजीनियर हैं, न कि “लाइट्स ऑन रखने” में लगाए गए जूनियर स्टाफ़।

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

• लेवल 1: आरंभ (Initiate)। अनुरक्षण अनियोजित और अवित्तपोषित है, जिसे जो भी खाली हो वह प्रतिक्रियात्मक रूप से संभालता है। इसे बग-फ़िक्सिंग और निम्न-दर्जे के काम के रूप में देखा जाता है। कोई श्रेणी ट्रैकिंग नहीं है, कोई लागत अनुमान नहीं है, और ज्ञान कुछ ही दिमाग़ों में रहता है। बदलाव की लागत बिना ध्यान दिए बढ़ती रहती है जब तक कि कोई फ़िक्स अटक न जाए या कोई संकट ध्यान न खींच ले।
• लेवल 2: विकास (Develop)। कुछ टीमों ने अनुरक्षण अनुरोधों को लॉग और ट्राइएज करना और एक बजट लाइन रखना शुरू कर दिया है, लेकिन प्रथा पूरे संगठन में असंगत है और बजट आमतौर पर एक अवशेष होता है। करेक्टिव काम ट्रैक किया जाता है जबकि अडैप्टिव और परफ़ेक्टिव प्रयास स्पष्ट रूप से अलग नहीं किए जाते। कुछ टेस्ट और दस्तावेज़ीकरण जेबों (pockets) में मौजूद हैं, इसलिए बदलाव आंशिक रूप से नियंत्रित है लेकिन समझ महँगी और टीम-दर-टीम असमान बनी रहती है।
• लेवल 3: मानकीकरण (Standardize)। एक परिभाषित अनुरक्षण प्रक्रिया (ISO/IEC 14764 के अनुसार) पूरे संगठन में दस्तावेज़ीकृत और लागू है: काम को चार श्रेणियों में वर्गीकृत किया जाता है, इम्पैक्ट एनालिसिस और चेंज मैनेजमेंट नियमित हैं, और अनुरक्षण का अनुमान लगाया जाता है और हर व्यावसायिक मामले में स्पष्ट रूप से वित्तपोषित किया जाता है। प्रिवेंटिव अनुरक्षण और रीफ़ैक्टरिंग एक ठोस टेस्ट सूट के तहत मानक प्रथा हैं, और अनुरक्षणीयता (विश्लेषणीयता, संशोधनीयता, टेस्ट करने योग्यता, मॉड्युलैरिटी) एक स्थानीय आदत के बजाय एक स्पष्ट डिज़ाइन आवश्यकता है।
• लेवल 4: प्रबंधन (Manage)। अनुरक्षण को बेसलाइन के मुक़ाबले डेटा से मापा और नियंत्रित किया जाता है। बदलाव-की-लागत संकेतक (चेंज लीड टाइम, चेंज फ़ेल्योर रेट, जटिलता व दोष रुझान) प्रति सिस्टम ट्रैक किए जाते हैं, चार-श्रेणी वाला प्रयास मिश्रण अपेक्षाओं के मुक़ाबले परिमाणित किया जाता है, और मेंटेनेंस-एफ़र्ट रेश्यो व पैरामीट्रिक अनुमानों की जाँच वास्तविक ऐतिहासिक बदलाव लागत के मुक़ाबले की जाती है। बढ़ता हुआ लागत वक्र एक अग्रणी संकेतक के रूप में पकड़ा जाता है और कार्रवाई ट्रिगर करता है, और प्रिवेंटिव आबंटन अनुमान के बजाय सबूत से तय किया जाता है। रीफ़ैक्टर, री-इंजीनियर, या रिटायर करने के निर्णय मापे गए थ्रेशोल्ड पर लिए जाते हैं, सहज ज्ञान (intuition) पर नहीं।
• लेवल 5: ऑर्केस्ट्रेशन (Orchestrate)। अनुरक्षण निरंतर सुधरता है और पूरे संगठन तथा उसके जीवनचक्र अर्थशास्त्र में एकीकृत है। जीवनचक्र TCO पोर्टफ़ोलियो निवेश को संचालित करता है, घटकों के बिगड़ने से पहले सोच-समझकर री-इंजीनियरिंग लागू की जाती है, ज्ञान को सक्रिय रूप से बनाए रखा जाता है, और रिटायरमेंट की योजना बनाई जाती है और नियमित रूप से निष्पादित की जाती है। जैसे-जैसे वातावरण बदलता है (नियमन, प्लेटफ़ॉर्म, डिपेंडेंसी), संगठन अनुरक्षण प्रयास को फिर से संतुलित करता है, अनुरक्षक सम्मानित वरिष्ठ इंजीनियर होते हैं, और पूरी संपत्ति (estate) अनुकूलित होती है ताकि दशकों तक जीने वाले सिस्टम में बदलाव की लागत स्थिर बनी रहे।

चर्चा के लिए विचार

1. आपके इंजीनियरिंग प्रयास का कितना हिस्सा वास्तव में अनुरक्षण में जाता है, और क्या आपका बजट व स्टाफ़िंग उस वास्तविकता को दर्शाते हैं?
2. क्या आप अपने अनुरक्षण काम को चार श्रेणियों में तोड़ सकते हैं, और क्या यह मिश्रण आपकी धारणाओं से मेल खाता है?
3. एक सामान्य बदलाव में से कितना हिस्सा सिस्टम को समझने में बनाम उसे संशोधित करने में खर्च होता है, और क्या चीज़ समझ को सस्ता बना सकती है?
4. क्या आपकी बदलाव की लागत समय के साथ बढ़ रही है, स्थिर है, या घट रही है, और क्या आप इसे बिल्कुल भी माप रहे हैं?
5. क्या आपकी टीमों के पास एक विश्वसनीय टेस्ट सेफ़्टी नेट है जो निरंतर रीफ़ैक्टरिंग को सुरक्षित बनाता है, या पुनर्संरचना का प्रयास करना बहुत जोखिम भरा है?
6. आपके सबसे दीर्घजीवी सिस्टम का अनुरक्षण कौन करता है, उनके ज्ञान को कैसे संचित किया जाता है, और उस काम का दर्जा व मनोबल क्या है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Software Maintenance knowledge area
• ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
• ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): maintainability quality characteristics
• Martin Fowler, Refactoring: Improving the Design of Existing Code
• Michael Feathers, Working Effectively with Legacy Code
• Thomas M. Pigoski, Practical Software Maintenance
• Penny Grubb and Armstrong A. Takang, Software Maintenance: Concepts and Practice
• Barry Boehm et al., Software Cost Estimation with COCOMO II (maintenance and reuse models)
• Meir M. Lehman, “Laws of Software Evolution” (on why software must continually change or become less useful)
• Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis, Modernizing Legacy Systems