Information Technology Problem Solving – The 6 Principles of Scientific Problem Solving

[ad_1]

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

समस्या समाधान के वैज्ञानिक दृष्टिकोण का पालन करने के बजाय समस्या समाधानकर्ता अनुमान क्यों लगाते हैं? शायद इसलिए कि यह जल्दी लगता है? शायद कुशल समस्या समाधान में अनुभव की कमी? या शायद इसलिए कि इसे वैज्ञानिक रूप से करना कठिन काम लगता है? हो सकता है कि जब आप अनुमान लगाते रहें और वास्तव में समाधान न करें, तो आप अधिक आय उत्पन्न करते हैं और कुछ नौकरी सुरक्षा जोड़ते हैं? या शायद इसलिए कि आप समस्या समाधान के पहले सिद्धांत का उल्लंघन करते हैं: समस्या को समझें।

सिद्धांत # 1। *वास्तविक* समस्या को समझें।

क्या यह स्पष्ट नहीं है कि इससे पहले कि आप हल कर सकें, आपको समस्या को समझना होगा? हो सकता है। लेकिन, अधिकांश समय सॉल्वर वास्तविक समस्या को जाने बिना ही हल करना शुरू कर देगा। ग्राहक या उपयोगकर्ता जिसे “समस्या” के रूप में वर्णित करते हैं, वह सामान्य रूप से केवल लक्षण है! “मेरा कंप्यूटर स्विच ऑन नहीं करना चाहता” इसका लक्षण है। असली समस्या यह हो सकती है कि पूरी इमारत बिना बिजली के है। “हर बार जब मैं एक नया उत्पाद जोड़ने का प्रयास करता हूं, तो मुझे एक त्रुटि संदेश मिलता है” यह लक्षण है। यहां असली समस्या हो सकती है “केवल पिछले 2 उत्पादों को मैंने जोड़ने की कोशिश की ‘उत्पाद पहले से मौजूद है’ त्रुटि”। एक और क्लासिक उदाहरण: “कुछ भी काम नहीं कर रहा है”…

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

एक वास्तविक जीवन उदाहरण। उपयोगकर्ता के अनुसार लक्षण: “जब मैं ऑर्डर देता हूं तो सिस्टम यादृच्छिक समय पर हैंग हो जाता है”। पर्यावरण: उपयोगकर्ता मेनफ्रेम एप्लिकेशन में फॉर्म पर ऑर्डर विवरण दर्ज करता है। जब सभी विवरण पूरे हो जाएंगे, तो उपयोगकर्ता फॉर्म को टैब कर देगा। मेनफ्रेम तब इस विवरण को संचार सॉफ्टवेयर के माध्यम से संयंत्र में एक Oracle क्लाइंट/सर्वर सिस्टम को भेजता है। Oracle सिस्टम कैपेसिटी प्लानिंग करेगा और मेनफ्रेम सिस्टम में या तो त्रुटि या अपेक्षित ऑर्डर की तारीख लौटाएगा। यह समस्या काफी गंभीर है, क्योंकि आप ग्राहकों को खो सकते हैं यदि वे ऑर्डर देने की कोशिश करते हैं और सिस्टम उन्हें स्वीकार नहीं करता है! इस समस्या को हल करने का प्रयास करने के लिए, लोगों ने जांच शुरू की: 1) मेनफ्रेम हार्डवेयर का भार और क्षमता 2) मेनफ्रेम और ओरेकल सिस्टम के बीच नेटवर्क लोड की निगरानी 3) संचार सॉफ्टवेयर को डीबग करने के लिए सलाहकारों को नियुक्त करना 4) ओरेकल क्षमता को डीबग करना योजना प्रणाली कुछ महीने बिताने के बाद भी वे समस्या का समाधान नहीं कर सके।

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

सिद्धांत # २। हल करने की प्रक्रिया शुरू करने से डरो मत, भले ही आप सिस्टम को न समझें।

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

प्रत्येक जटिल प्रणाली में कुछ बुनियादी कार्य सिद्धांत होते हैं। सिस्टम ए जो सिस्टम बी से डेटा पढ़ता है वह बहुत जटिल हो सकता है (शायद एक प्रयोगशाला स्पेक्ट्रोमीटर जो एक प्रोग्रामेबल लॉजिक कंप्यूटर से आरएस -232 पोर्ट के माध्यम से डेटा पढ़ता है)। लेकिन, परीक्षण करने के लिए कुछ मूल बातें: क्या दोनों प्रणालियों में शक्ति है? क्या इनमें से किसी एक सिस्टम पर इवेंट लॉग में कोई त्रुटि संदेश है? क्या आप एक सिस्टम से दूसरे सिस्टम में नेटवर्क पैकेट को “पिंग” या ट्रेस कर सकते हैं? एक अलग संचार केबल का प्रयास करें। त्रुटि संदेश के लिए इंटरनेट पर खोजें।

एक बार जब आप यह स्थापित कर लें कि समस्या क्या है, तो आपको इसे हल करना शुरू करना होगा। कभी-कभी प्रारंभिक जांच आपको सीधे समाधान की ओर संकेत करेगी (पावर चालू करें; दोषपूर्ण केबल को बदलें, आदि)। लेकिन, कभी-कभी वास्तविक समस्या अपने आप में जटिल होती है, इसलिए अगला सिद्धांत इसे सरल तरीके से हल करना है।

सिद्धांत #3। इसे सरल जीतो।

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

“समस्या सॉल्वर” ने जो किया, वह समस्या को दोहराने के लिए था और साथ ही उस कोड को अलग करने की कोशिश की जो समस्या का कारण बना। ऐसा करने में, जटिल (और समय लेने वाली) संग्रहीत प्रक्रिया कुछ तेज और सरल बन गई।

यदि समस्या किसी एप्लिकेशन के अंदर है, तो एक नया एप्लिकेशन बनाएं और नए एप्लिकेशन के अंदर समस्या को यथासंभव सरल बनाने का प्रयास करें। यदि समस्या तब होती है जब एक निश्चित नियंत्रण के लिए एक निश्चित विधि को कॉल किया जाता है, तो केवल इस नियंत्रण को खाली एप्लिकेशन में शामिल करने का प्रयास करें और उस विधि को हार्ड-कोडेड मानों के साथ कॉल करें। यदि समस्या C# एप्लिकेशन के अंदर एम्बेडेड SQL के साथ है, तो डेटाबेस क्वेरी टूल के अंदर SQL को अनुकरण करने का प्रयास करें (जैसे Oracle के लिए SQL*Plus, SQL सर्वर के लिए क्वेरी एनालाइज़र, या डेटाबेस में ODBC के माध्यम से MS Excel में कोड का उपयोग करें) )

जिस क्षण आप समस्या को सरल तरीके से दोहरा सकते हैं, आप इसे हल करने के अपने रास्ते पर 80% से अधिक हैं।

यदि आप नहीं जानते कि प्रोग्राम में समस्या कहाँ है, तो DEBUG का उपयोग करें।

सिद्धांत # 4। डिबग।

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

पहली चीज जो आप डीबगर के साथ करना चाहते हैं वह यह निर्धारित करना है कि समस्या कहां है। आप प्रमुख क्षेत्रों में ब्रेकप्वाइंट जोड़कर ऐसा करते हैं। फिर आप प्रोग्राम को डिबग मोड में चलाते हैं और आपको पता चल जाएगा कि किन ब्रेकप्वाइंट के बीच समस्या हुई। नीचे ड्रिल करें और आपको जगह मिल जाएगी। अब जब आप जानते हैं कि समस्या कहाँ है, तो आप “इसे सरल तरीके से जीत सकते हैं”

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

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

सिद्धांत # 5। डेटाबेस बैक-एंड पर जानकारी का खजाना है जो किसी समस्या को हल करने में मदद करेगा।

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

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

आप बैक-एंड डेटाबेस पर कैसे पता लगाते हैं कि क्या हो रहा है? मुख्य डेटाबेस प्रदाताओं के पास GUI उपकरण होते हैं जो आपको यह पता लगाने या विश्लेषण करने में मदद करते हैं कि डेटाबेस के विरुद्ध कौन से प्रश्न निकाले गए हैं। यह आपको तब भी दिखाएगा जब लोग सुरक्षा उल्लंघनों के कारण कनेक्ट, डिस्कनेक्ट या कनेक्ट करने में असमर्थ थे। अधिकांश डेटाबेस में कुछ सिस्टम डिक्शनरी टेबल भी शामिल होते हैं जिन्हें यह जानकारी प्राप्त करने के लिए पूछताछ की जा सकती है। ये निशान कभी-कभी पूरी कहानी बता सकते हैं कि कुछ विफल क्यों हो रहा है। ट्रेस से आपके द्वारा पुनर्प्राप्त किया गया क्वेरी कोड “खोज को सरल बनाने” में मदद कर सकता है। आप ट्रेस से देख सकते हैं कि प्रोग्राम डेटाबेस के साथ सफल संपर्क बनाता है या नहीं। आप देख सकते हैं कि किसी क्वेरी को निष्पादित करने में कितना समय लगता है।

सिद्धांत#2 में जोड़ने के लिए (शुरू करने से न डरें…); आप इस ट्रेस जानकारी का विश्लेषण कर सकते हैं, भले ही आपको एप्लिकेशन के विवरण के बारे में कुछ भी पता न हो।

हालांकि याद रखें कि ये बैक-एंड ट्रेस बैक-एंड संसाधनों पर दबाव डाल सकते हैं। उन्हें अनावश्यक देर तक दौड़ना न छोड़ें।

सिद्धांत #6। ताजा आंखों का प्रयोग करें।

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

निष्कर्ष

इस पेपर को पढ़ने के बाद, लेखक को उम्मीद है कि अगली बार जब आप किसी समस्या को हल करने के लिए आएंगे तो आप इन्हें आजमाएंगे। उम्मीद है कि इन छह सिद्धांतों को लागू करने से आप समाधान के अपने तरीके का “अनुमान” लगाने के बजाय उनके द्वारा लाए गए लाभों को महसूस करेंगे।

[ad_2]

Leave a Reply

Your email address will not be published. Required fields are marked *