About software and domain problem in Hindi सॉफ्टवेयर और डोमेन संबंधित तथ्य एवम् समस्याएं।

 

डोमेन समस्या ( domain problem)

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

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

 दूसरी ओर, एक औद्योगिक शक्ति सॉफ्टवेयर सिस्टम, किसी ग्राहक की कुछ समस्या को हल करने के लिए बनाया जाता है और इसका उपयोग क्लाइंट संगठन द्वारा व्यवसाय के कुछ भाग को संचालित करने के लिए किया जाता है (हम "व्यवसाय" शब्द का उपयोग बहुत व्यापक अर्थ में करते हैं - यह इन्वेंट्री, वित्त, रोगियों की निगरानी, ​​एयर ट्रैफ़िक नियंत्रक का प्रबंधन करना हो सकता है।) दूसरे शब्दों में, महत्वपूर्ण गतिविधियाँ सिस्टम के सही कामकाज पर निर्भर करती हैं। और इस तरह की प्रणाली की खराबी से वित्तीय या व्यावसायिक नुकसान, उपयोगकर्ताओं को असुविधा, या संपत्ति और जीवन की हानि के मामले में बहुत बड़ा प्रभाव पड़ सकता है। नतीजतन, सॉफ़्टवेयर सिस्टम को निर्भरता, विश्वसनीयता, उपयोगकर्ता-मित्रता आदि जैसे गुणों के संबंध में उच्च गुणवत्ता का होना चाहिए। उच्च गुणवत्ता की इस आवश्यकता के कई निहितार्थ हैं। सबसे पहले, इसके लिए आवश्यक है कि उपयोग किए जाने से पहले सॉफ़्टवेयर का पूरी तरह से परीक्षण किया जाए। कठोर परीक्षण की आवश्यकता लागत को काफी बढ़ा देती है।  औद्योगिक शक्ति सॉफ्टवेयर परियोजना में, कुल प्रयास का 30% से 50% परीक्षण में खर्च किया जा सकता है जबकि छात्र सॉफ्टवेयर में 5% भी बहुत अधिक हो सकता है!) computer system threat

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

सॉफ्टवेयर महंगा( expensive software)

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

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

नए कोड लिखने के लिए सॉफ़्टवेयर उद्योग में उत्पादकता आम तौर पर प्रति व्यक्ति-महीना 300 से 1,000 LOG तक होती है। यानी, सॉफ़्टवेयर विकसित करने के लिए, पूरे विकास चक्र में प्रति व्यक्ति, प्रति माह औसत उत्पादकता लगभग 300 से 1,000 LOG है।  और सॉफ्टवेयर कंपनियां उस क्लाइंट से, जिसके लिए वे सॉफ्टवेयर विकसित कर रही हैं, प्रति व्यक्ति-वर्ष $100,000 या प्रति व्यक्ति-माह $8,000 से अधिक शुल्क लेती हैं (जो लगभग $50 प्रति घंटा होता है)। उद्योग के वर्तमान उत्पादकता आंकड़ों के साथ, यह लगभग $8 से $25 के कोड की प्रति पंक्ति लागत में तब्दील हो जाता है। दूसरे शब्दों में, वर्तमान लागत और उत्पादकता स्तरों पर वितरित कोड की प्रत्येक पंक्ति की लागत $8 से $25 के बीच होती है! और यहां तक ​​कि छोटी परियोजनाएं भी आसानी से 50,000 LOG के सॉफ्टवेयर के साथ समाप्त हो सकती हैं। इस उत्पादकता के साथ, इस तरह के एक सॉफ्टवेयर प्रोजेक्ट की लागत $0.5 मिलियन से $1.25 मिलियन के बीच होगी!

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

देर से और अविश्वसनीय(late and unreliable)

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

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

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

रखरखाव और पुनःकार्य(maintenance and rework)

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

हालांकि रखरखाव को सॉफ्टवेयर विकास का हिस्सा नहीं माना जाता है, लेकिन यह सॉफ्टवेयर उत्पाद के जीवन में एक अत्यंत महत्वपूर्ण गतिविधि है। यदि हम सॉफ्टवेयर के कुल जीवन पर विचार करते हैं, तो रखरखाव की लागत आम तौर पर सॉफ्टवेयर के विकास की लागत से अधिक होती है। रखरखाव-से-विकास-लागत अनुपात को विभिन्न रूप से 80:20, 70:30, या 60:40 के रूप में सुझाया गया है। रखरखाव की लागत कैसे बढ़ रही है।

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

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

रखरखाव परिवर्तन का एक रूप है जो आम तौर पर सॉफ़्टवेयर के पूरा होने और सॉफ़्टवेयर को तैनात किए जाने के बाद किया जाता है। हालाँकि, ऐसे अन्य प्रकार के परिवर्तन भी हैं जो सॉफ़्टवेयर विकास के दौरान ही पुनः कार्य करने की ओर ले जाते हैं।

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

Faq 

Question-1 सॉफ्टवेयर और डोमेन की मुख्य समस्या क्या है?

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

सॉफ्टवेयर महंगा

देर से और अविश्वसनीय

रखरखाव और पुनःकार्य