सॉफ्टवेयर संरक्षण

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

इतिहास

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

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

सॉफ्टवेयर रखरखाव का महत्व

प्रमुख सॉफ़्टवेयर रखरखाव मुद्दे प्रबंधकीय और तकनीकी हैं। प्रबंधन के मुद्दों में ग्राहकों की प्राथमिकताओं के साथ संरेखण, स्टाफिंग, जिम्मेदारियां सौंपना और लागत का अनुमान लगाना शामिल है। तकनीकी मुद्दों में शामिल हैं: सीमित समझ, परिवर्तन प्रभाव विश्लेषण, परीक्षण और रखरखाव माप।

सॉफ्टवेयर रखरखाव एक व्यापक गतिविधि है जिसमें त्रुटि सुधार, क्षमताओं में वृद्धि, अप्रचलित क्षमताओं को हटाना और अनुकूलन शामिल है। क्योंकि परिवर्तन अपरिहार्य है, मूल्यांकन, नियंत्रण और संशोधन करने के लिए तंत्र विकसित किया जाना चाहिए।

सॉफ़्टवेयर के परिनियोजित होने के बाद उस पर किया गया कोई भी कार्य रखरखाव माना जाता है। रखरखाव समय के साथ सॉफ्टवेयर के मूल्य को बरकरार रखता है। ग्राहक आधार का विस्तार करके, नई और अतिरिक्त आवश्यकताओं को पूरा करके, उपयोग में आसान, अधिक कुशल और नई तकनीक को नियोजित करके मूल्य बढ़ाया जा सकता है। रखरखाव में दशकों लग सकते हैं, जबकि प्रारंभिक विकास आमतौर पर 3 साल से कम होता है।

सॉफ्टवेयर रखरखाव योजना

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

सॉफ्टवेयर रखरखाव प्रक्रिया

यह खंड छह सॉफ्टवेयर रखरखाव प्रक्रियाओं का वर्णन इस प्रकार करता है:

1. कार्यान्वयन - सॉफ़्टवेयर तैयार करना और संक्रमण गतिविधियाँ, जैसे रखरखाव योजना का निर्माण; विकास के दौरान पहचानी गई समस्याओं से निपटने की तैयारी; और उत्पाद विन्यास प्रबंधन पर अनुवर्ती।
2. समस्या और संशोधन विश्लेषण - अनुरोधों और समस्याओं की पुष्टि (पुनरुत्पादन), विश्लेषण और जांच की जाती है। समाधान प्रस्तावित और प्रलेखित हैं। संशोधनों को लागू करने के लिए प्राधिकरण प्राप्त किया जाता है।
3. संशोधन कार्यान्वयन - सॉफ़्टवेयर कोड, डेटा और / या कॉन्फ़िगरेशन को अद्यतन, संकलित और पुन: तैनात किया गया है।
4. संशोधन स्वीकृति - जिस व्यक्ति ने अनुरोध प्रस्तुत किया है वह इस बात की पुष्टि करने के लिए सॉफ़्टवेयर का संचालन/परीक्षण करता है कि समस्या का समाधान हो गया है।
5. माइग्रेशन (उदाहरण के लिए सॉफ़्टवेयर माइग्रेशन) असाधारण है, और दैनिक रखरखाव कार्यों का हिस्सा नहीं है। यदि सॉफ्टवेयर को कार्यक्षमता में किसी भी बदलाव के बिना किसी अन्य प्लेटफॉर्म पर पोर्ट किया जाना चाहिए, तो इस प्रक्रिया का उपयोग किया जाएगा और इस कार्य के लिए एक रखरखाव परियोजना टीम को सौंपे जाने की संभावना है।
6. अप्रचलित/प्रतिस्थापित सॉफ्टवेयर घटकों की सेवानिवृत्ति। यह आमतौर पर दैनिक आधार पर नहीं होता है।

ऐसी कई प्रक्रियाएँ, गतिविधियाँ और प्रथाएँ हैं जो अनुरक्षकों के लिए अद्वितीय हैं, उदाहरण के लिए:

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

सॉफ्टवेयर रखरखाव की श्रेणियाँ

ई.बी. स्वानसन ने शुरू में रखरखाव की तीन श्रेणियों की पहचान की: सुधारात्मक, अनुकूली और पूर्ण। IEEE 1219 मानक को जून 2010 में P14764 द्वारा प्रतिस्थापित किया गया था। तब से इन्हें अद्यतन किया गया है और ISO/IEC 14764 प्रस्तुत करता है:

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

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

रखरखाव कारक

रखरखाव पर प्रमुख समायोजन कारकों का प्रभाव (अधिकतम सकारात्मक प्रभाव के क्रम में क्रमबद्ध)

Maintenance Factors	Plus Range
Maintenance specialists	35%
High staff experience	34%
Table-driven variables and data	33%
Low complexity of base code	32%
Y2K and special search engines	30%
Code restructuring tools	29%
Re-engineering tools	27%
High level programming languages	25%
Reverse engineering tools	23%
Complexity analysis tools	20%
Defect tracking tools	20%
Y2K “mass update” specialists	20%
Automated change control tools	18%
Unpaid overtime	18%
Quality measurements	16%
Formal base code inspections	15%
Regression test libraries	15%
Excellent response time	12%
Annual training of > 10 days	12%
High management experience	12%
HELP desk automation	12%
No error prone modules	10%
On-line defect reporting	10%
Productivity measurements	8%
Excellent ease of use	7%
User satisfaction measurements	5%
High team morale	5%
Sum	503%

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

रखरखाव पर प्रमुख समायोजन कारकों का प्रभाव (अधिकतम नकारात्मक प्रभाव के क्रम में क्रमबद्ध)

Maintenance Factors	Minus Range
Error prone modules	-50%
Embedded variables and data	-45%
Staff inexperience	-40%
High code complexity	-30%
No Y2K of special search engines	-28%
Manual change control methods	-27%
Low level programming languages	-25%
No defect tracking tools	-24%
No Y2K “mass update” specialists	-22%
Poor ease of use	-18%
No quality measurements	-18%
No maintenance specialists	-18%
Poor response time	-16%
No code inspections	-15%
No regression test libraries	-15%
No help desk automation	-15%
No on-line defect reporting	-12%
Management inexperience	-15%
No code restructuring tools	-10%
No annual training	-10%
No reengineering tools	-10%
No reverse-engineering tools	-10%
No complexity analysis tools	-10%
No productivity measurements	-7%
Poor team morale	-6%
No user satisfaction measurements	-4%
No unpaid overtime	0%
Sum	-500%

रखरखाव ऋण

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

मालिक को तब पता चल सकता है कि सिस्टम को अब संशोधित नहीं किया जा सकता है - यह वस्तुतः अप्राप्य है। कम नाटकीय रूप से, व्यवसाय की समस्या को हल करने के लिए रखरखाव के लिए बहुत अधिक समय लग सकता है, या बहुत अधिक लागत आ सकती है, और एक वैकल्पिक समाधान खोजा जाना चाहिए। सॉफ़्टवेयर अचानक £0 मान पर क्रैश हो गया है।

एस्टडेल रखरखाव ऋण को परिभाषित करता हैके रूप में: एक आवेदन की वर्तमान कार्यान्वयन स्थिति और आदर्श के बीच का अंतर, केवल बाहरी घटकों की कार्यक्षमता का उपयोग करके जो पूरी तरह से बनाए रखा और समर्थित है। यह ऋण अक्सर छिपा होता है या पहचाना नहीं जाता है। एक आवेदन की समग्र रखरखाव अन्य आपूर्तिकर्ताओं से सभी प्रकार के घटकों की निरंतर प्राप्यता पर निर्भर है, जिनमें निम्न शामिल हैं:

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

और ज़ाहिर सी बात है कि

• प्रासंगिक कौशल की उपलब्धता, इन-हाउस या बाज़ार में।

एक घटक का पूर्ण रूप से गायब होना अनुप्रयोग को पुन: निर्माण योग्य नहीं बना सकता है, या आसन्न रूप से अप्राप्य बना सकता है।

यह भी देखें

• आवेदन सेवानिवृत्ति
• जर्नल ऑफ सॉफ्टवेयर मेंटेनेंस एंड इवोल्यूशन: रिसर्च एंड प्रैक्टिस
• दीर्घकालिक समर्थन
• खोज आधारित सॉफ्टवेयर इंजीनियरिंग
• सॉफ्टवेयर पुरातत्व
• सॉफ्टवेयर मेंटेनर
• सॉफ्टवेयर डेवलपमेंट

अग्रिम पठन

• ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. 2006. doi:10.1109/IEEESTD.2006.235774. ISBN 0-7381-4960-8.
• Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
• Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area.
• April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0-470-14707-8.
• Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
• Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
• Lehman, M.M.; Belady, L.A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 0-12-442441-4.
• Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 0-917072-17-0.

बाहरी संबंध

• Journal of Software Maintenance