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

From Vigyanwiki

सॉफ्टवेयर इंजीनियरिंग में सॉफ्टवेयर संरक्षण (सॉफ्टवेयर मेंटेनेंस) उत्पाद के डिलीवरी के बाद संशोधन होता है, जिससे फॉल्ट्स को सही किया जा सके, प्रदर्शन या अन्य गुणवत्ताओं को बेहतर बनाया जा सके।[1][2]

एक सामान्य मान्यता है कि मेंटेनेंस बस दोषों को ठीक करने में ही सम्मलित है। चूंकि, एक अध्ययन ने बताया कि मेंटेनेंस के अधिकांश प्रयास गैर-सुधारात्मक कार्रवाईयों के लिए होते हैं। उपयोगकर्ताओं के माध्यम से समस्या रिपोर्ट जमा करने से यह मान्यता फैली रहती है जो वास्तव में सिस्टम में कार्यक्षमता में सुधार हैं। नवीनतम अध्ययन बग-फिक्सिंग का अनुपात करीब 21% के निकट हैं।[3]


इतिहास

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

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


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

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

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

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

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

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

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

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

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

बनाए रखनेवालों के लिए कई प्रक्रियाएं, गतिविधियां और अभ्यास होते हैं, जैसे:

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

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

ईबी स्वान्सन ने शुरुआत में मेंटेनेंस के तीन श्रेणियाँ निर्दिष्ट की थीं: सुधारात्मक, अनुकूलतात्मक और पूर्णात्मक।[7] जून 2010 में आईईईई 1219 मानक को पी14764 के माध्यम से उल्लंघन किया गया था।[8]इन्हें बाद में अपडेट किया गया है और आईएसओ / आईईसी 14764 प्रस्तुत करता है:

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

पूर्व-वितरण / पूर्व-रिलीज रखरखाव का भी एक अवधारणा है जो सॉफ्टवेयर के कुल स्वामित्व लागत को कम करने के लिए आप करते हैं। कोडिंग मानकों के अनुसार अनुरक्षितता के लक्ष्य सम्मलित होने जैसी बातें। सॉफ्टवेयर के युग्मन और सामंजस्य का प्रबंधन। सॉफ्टवेयर के कपलिंग और कोहीशन के प्रबंधन। सॉफ्टवेयर समर्थन लक्ष्यों (उदाहरण के लिए एसएई जेए1004, जेए1005 और जेए1006) की प्राप्ति। कुछ शैक्षिक संस्थान[who?] ऐसे अनुसंधान कर रहे हैं जो संसाधन जैसे डिजाइन दस्तावेज और सिस्टम / सॉफ्टवेयर समझने के प्रशिक्षण और संसाधनों की कमी के कारण लगातार सॉफ्टवेयर रखरखाव की लागत का मापन करने के लिए (प्राप्त नहीं होने पर लगातार लागतों को अधिकतर 1.5-2.0 से गुणा करें)।

रखरखाव कारक

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

रखरखाव कारक प्लस रेंज
रखरखाव विशेषज्ञ 35%
उच्च कर्मचारी अनुभव 34%
तालिका-संचालित चर और डेटा 33%
आधार कोड की कम जटिलता 32%
Y2K और विशेष खोज इंजन 30%
कोड पुनर्गठन उपकरण 29%
री-इंजीनियरिंग उपकरण 27%
उच्च स्तरीय प्रोग्रामिंग भाषाएं 25%
रिवर्स इंजीनियरिंग उपकरण 23%
जटिलता विश्लेषण उपकरण 20%
दोष ट्रैकिंग उपकरण 20%
Y2K "मास अपडेट" विशेषज्ञ 20%
स्वचालित परिवर्तन नियंत्रण उपकरण 18%
अवैतनिक ओवरटाइम 18%
गुणवत्ता माप 16%
औपचारिक आधार कोड निरीक्षण 15%
प्रतिगमन परीक्षण पुस्तकालय 15%
उत्कृष्ट प्रतिक्रिया समय 12%
> 10 दिनों का वार्षिक प्रशिक्षण 12%
उच्च प्रबंधन अनुभव 12%
हेल्प डेस्क स्वचालन 12%
कोई त्रुटि प्रवण मॉड्यूल नहीं 10%
ऑन लाइन दोष रिपोर्टिंग 10%
उत्पादकता माप 8%
उपयोग में उत्कृष्ट आसानी 7%
उपयोगकर्ता संतुष्टि माप 5%
उच्च टीम मनोबल 5%
योग 503%

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

मैंटेनेंस पर मुख्य समायोजन कारकों के प्रभाव (अधिकतम नकारात्मक प्रभाव के क्रम में सॉर्ट किए गए) का वर्णन नीचे है:

रखरखाव कारक माइनस रेंज
त्रुटि प्रवण मॉड्यूल -50%
एंबेडेड चर और डेटा -45%
कर्मचारी अनुभवहीनता -40%
उच्च कोड जटिलता -30%
विशेष खोज इंजनों का कोई Y2K नहीं -28%
मैनुअल परिवर्तन नियंत्रण के तरीके -27%
निम्न स्तर की प्रोग्रामिंग भाषाएँ -25%
कोई दोष ट्रैकिंग उपकरण नहीं -24%
कोई Y2K "मास अपडेट" विशेषज्ञ नहीं -22%
उपयोग में आसानी -18%
कोई गुणवत्ता माप नहीं -18%
कोई रखरखाव विशेषज्ञ नहीं -18%
खराब प्रतिक्रिया समय -16%
कोई कोड निरीक्षण नहीं -15%
कोई प्रतिगमन परीक्षण पुस्तकालय नहीं -15%
कोई हेल्प डेस्क स्वचालन नहीं -15%
कोई ऑनलाइन दोष रिपोर्टिंग नहीं -12%
प्रबंधन अनुभवहीनता -15%
कोई कोड पुनर्गठन उपकरण नहीं -10%
कोई वार्षिक प्रशिक्षण नहीं -10%
कोई पुनर्रचना उपकरण नहीं -10%
कोई रिवर्स-इंजीनियरिंग उपकरण नहीं -10%
कोई जटिलता विश्लेषण उपकरण नहीं -10%
कोई उत्पादकता माप नहीं -7%
खराब टीम मनोबल -6%
कोई उपयोगकर्ता संतुष्टि माप नहीं -4%
कोई अवैतनिक ओवरटाइम नहीं 0%
योग -500%

रखरखाव ऋण

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

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

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

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

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

यह भी देखें

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

संदर्भ

[11]

  1. ↑ "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. Retrieved 2013-12-02.
  2. ↑ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020-10-01). "सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल". Information and Software Technology (in English). 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  3. ↑ Eick, S., Graves, T., Karr, A., Marron, J., and Mockus, A. 2001. Does Code Decay? Assessing Evidence from Change Management Data. IEEE Transactions on Software Engineering. 27(1) 1-12.
  4. ↑ Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
  5. ↑ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076
  6. ↑ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
  7. ↑ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (June 1978). "E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497". Communications of the ACM. Portal.acm.org. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091. Retrieved 2013-12-02.
  8. ↑ Status of 1219-1998 by IEEE Standards
  9. ↑ Khan, O; Marchbank, P; Georgiadou, E; Linecar, P; Ross, M; Staples, G (2019). Proc of Software Quality Management XXVII: International Experiences and Initiatives in IT Quality Management. Southampton: Solent University. ISBN 978-1-9996549-2-4.
  10. ↑ 10.0 10.1 Estdale, John. मेंटेनेंस में देरी जानलेवा साबित हो सकती है. in [11]. pp. 95–106.
  11. ↑ Pigoski, Thomas. "Chapter 6: Software Maintenance" (PDF). SWEBOK. IEEE. Retrieved 5 November 2012.


अग्रिम पठन

  • 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.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_संरक्षण&oldid=270694’