Software engineering testability and maintainability support change and defect removal in hindi सॉफ्टवेयर इंजीनियरिंग परीक्षण योग्यता और रख-रखाव समर्थन परिवर्तन और दोष निवारण हिंदी में

 

परीक्षण योग्यता और रखरखाव योग्यता का समर्थन(  testability and maintainability)

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

        

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

Requirements - 10%

Design.         -    20%

Code.           - 30%

Testing.         -   40%

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

Writing program.       - 12%

Reading program.     - 17%

Job                           -   31%

Other.                       -   40%

यह डेटा स्पष्ट रूप से दर्शाता है कि प्रोग्रामिंग वह प्रमुख गतिविधि नहीं है जिस पर प्रोग्रामर अपना समय व्यतीत करते हैं।  भले ही हम "अन्य" गतिविधियों में बिताए गए समय को हटा दें, फिर भी प्रोग्रामर द्वारा प्रोग्राम लिखने में बिताया गया समय शेष समय का 25% से भी कम है।Software engineering process, components of software process and predictability in hindi सॉफ्टवेयर इंजीनियरिंग प्रक्रिया, सॉफ्टवेयर प्रक्रिया के घटक और पूर्वानुमानशीलता हिंदी में

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

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

परिवर्तन का समर्थन ( support change)

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

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

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

दोष निवारण( defect removal)

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

चरण के अनुसार त्रुटि घटनाओं का एक उदाहरण वितरण है:

Requirements.         -    22%

Design.                    -     28%

Coding.                   -      50%

त्रुटियाँ विकास प्रक्रिया के दौरान होती हैं। हालाँकि, विभिन्न चरणों की त्रुटियों को ठीक करने की लागत समान नहीं होती है और यह इस बात पर निर्भर करती है कि त्रुटि का पता कब लगाया गया और उसे कब ठीक किया गया। आवश्यकता त्रुटियों को ठीक करने की सापेक्ष लागत, जहाँ उनका पता लगाया गया है, के आधार पर चित्र में दिखाई गई है।

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

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

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

FAQ 

Question-1 सॉफ्टवेयर विकास कार्य मै प्रवर्तन का क्या नियम है?

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