क्या एक विश्लेषण प्रौद्योगिकी-अज्ञेयवादी होना चाहिए? [बन्द है]

Question

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

क्या मैं उस तरह से सोचना सही हूँ? क्या कोई कारण है कि एक व्यापार विश्लेषक को सिस्टम को लागू करने के लिए उपयोग की जाने वाली तकनीक को जानने की आवश्यकता होगी?

संपादित करें: मेरा मानना ​​है कि मैंने गलत शब्द का इस्तेमाल किया था business analyst। शायद मेरा मतलब आर्किटेक्ट, या सिस्टम एनालिस्ट से था। मुझे इन शब्दों की आदत नहीं है। अगर आप चाहें तो मुझे आर्किटेक्ट या सिस्टम एनालिस्ट से कुछ मतलब था।

अपने भयानक जवाब के लिए आप सभी को धन्यवाद! मैं अभी तक बहुत अनुभवी नहीं हूँ और मुझे खुशी है कि आपने इस पर अपनी आँखें खोलीं।

Comments

क्या आपने उससे एक उदाहरण के लिए पूछा कि इससे क्या फर्क पड़ेगा?

— कार्ल बेज़ेलफेल्ट

उन्होंने मुझे एक उदाहरण नहीं दिया, लेकिन हम पुराने एएस / 400 सिस्टम, कुछ डेल्फी और फिर। नेट से कुछ भी नया करने के लिए कई तरह की तकनीकों का उपयोग कर रहे हैं। लेकिन मुझे अभी भी लगता है कि अगर आप किसी ऐसी चीज़ को डिज़ाइन करते हैं जिसे आरपीजी में लागू किया जाना है, तो आप इसे सी # में उसी तरह से डिज़ाइन करेंगे जैसे कि चिंताओं के पृथक्करण का उपयोग करना, और व्यापार तर्क के लिए एक उचित परत, आदि

— मार्को-फिसेट

वह उपयोगकर्ता के रूप में ज्यादा जानने की जरूरत होगी। एएस / 400 बनाम एक वेब ऐप एक ऐसा विवरण है जिसकी उसे आवश्यकता होगी।

— कोडर

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

— कोडर

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

— गहोआ

Answer 1

निश्चित रूप से ऐसे मामले हैं जहां यह एक व्यापारिक विश्लेषक के लिए प्रौद्योगिकी को समझने के लिए कम से कम अच्छी तरह से समझने के लिए समझ में आता है, जहां यह समझ में आता है कि किसी व्यावसायिक उपयोगकर्ता के लिए यह सवाल करना महत्वपूर्ण है कि कोई विशेष सुविधा कितनी महत्वपूर्ण है। उदाहरण के लिए, यदि व्यवसाय एक मोटी क्लाइंट एप्लिकेशन के व्यवहार का आदी है, जबकि नया एप्लिकेशन वेब-आधारित होने जा रहा है, तो संभावना है कि कई "आवश्यकताएं" होंगी जो एक मोटी क्लाइंट में तुच्छ होगी लेकिन अपेक्षाकृत कठिन वेब-आधारित अनुप्रयोग के साथ। यदि व्यवसाय विश्लेषक समझता है कि व्यवसाय से एक अनुरोध विकास टीम के लिए तुच्छ हो रहा है या क्या यह AJAX विकास के 20 घंटे को शामिल करने जा रहा है,

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

Comments

"लागत को कम करते हुए व्यवसाय के लिए लाभ को अधिकतम करता है" के लिए +1। यह बीए की समझ के बिना नहीं किया जा सकता है। उच्च स्तर पर प्रोग्रामर की तुलना में अधिक टेक्नोलोजी को समझने के लिए बीए की नौकरी।

— मटनज़

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

— BiGXERO

Answer 2

इस मुद्दे के दोनों पक्षों पर काम करने के बाद मुझे विश्लेषक से सहमत होना होगा। मैंने प्रौद्योगिकी की क्षमताओं की समझ की कमी के परिणामस्वरूप कुछ शानदार खराब डिजाइन देखे हैं। कुछ मामलों में, यह विपणन प्रचार को सच्चाई के रूप में लेने का एक परिणाम है। सामान्य तौर पर, समस्या विशिष्टताओं को उत्पन्न करती रही है जो तकनीकी क्षमताओं से मेल नहीं खाती है।

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

सीमाओं को धक्का देने से कई तरीकों से लागत बढ़ सकती है, लेकिन कुछ मामलों में महत्वपूर्ण रिटर्न हो सकता है। लागत कारकों में से कुछ हैं:

• कार्यशील समाधान विकसित करने के लिए प्रयोग की आवश्यकता हो सकती है;
• विशेष ज्ञान वाले नए कर्मचारियों या सलाहकारों का अधिग्रहण करने की आवश्यकता हो सकती है;
• नई तकनीक पर प्रशिक्षण की आवश्यकता हो सकती है;
• विकास धीमा और बग दर अधिक हो जाता है; तथा
• अतिरिक्त प्रयासों से सरल समाधानों में देरी हो सकती है जिनके अधिक तत्काल मूल्य हैं।

Answer 3

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

हालांकि, व्यापार विश्लेषकों को इस बात की परवाह नहीं करनी चाहिए कि किस तकनीक का उपयोग किया जाता है, उनका काम व्यावसायिक नियमों को इकट्ठा करना और उन्हें तकनीकी टीम के लिए समझने योग्य बनाना है। सिस्टम एनालिस्ट / आर्किटेक्ट्स / डिज़ाइनर या कोई अन्य नाम जो उन्हें दिया जा सकता है, उन्हें इस्तेमाल की जा रही तकनीकों को जानना चाहिए और उनके चारों ओर डिज़ाइन करना चाहिए क्योंकि वे वास्तविक डिज़ाइन करने वाले होने चाहिए, न कि बिजनेस एनालिस्ट।

Answer 4

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

क्या कोई परिचालन पैरामीटर नहीं हैं जो आपको एक विशिष्ट दिशा में ड्राइव करते हैं? क्या आपके पास संसाधनों की एक विस्तृत सरणी है जो किसी भी प्रौद्योगिकी स्टैक में समाधान को लागू करने में सक्षम है? क्या अन्य प्रणालियों तक पहुंच की आवश्यकता के लिए इंटरऑपरेबिलिटी समस्याएं हैं?

इन सवालों के जवाब की जरूरत है इससे पहले कि आप निश्चित रूप से कह सकें कि क्या प्रौद्योगिकी समीकरण का हिस्सा होना चाहिए या क्या डिजाइन को प्रौद्योगिकी चयन को चलाना चाहिए।

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

Answer 5

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

Answer 6

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

Answer 7

व्यवसाय विश्लेषक को यह पता होना चाहिए कि हम किस तरह के एप्लिकेशन को विकसित कर रहे हैं जैसे * वेब एप्लीकेशन / कंसोल एप्लीकेशन / मोबाइल एप्लिकेशन / रिपोर्टिंग एप्लिकेशन आदि * ताकि वह बेहतर तरीके से एप्लिकेशन के लिए अच्छे फीचर के साथ आ सके या उपयोगकर्ता को पीछे धकेल सके। 3rd लेवल नेस्टेड ड्रैग एंड ड्रॉप (जैसे) जैसी असंभव उम्मीदों पर।

उसे / उसे कौन सी तकनीक जैसे जावा / सी # / पायथन / एसक्यूएल आदि के बारे में पता करने की आवश्यकता नहीं है ।

Answer 8

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

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

Answer 9

प्रत्येक तकनीक की सीमाएं और बाधाएं होती हैं, इसलिए यह विश्लेषक के लिए उन सीमाओं पर विचार करने के लिए कुछ समझ में आता है। दूसरी ओर, एक विश्लेषक जो अच्छी तरह से जानता है। लेकिन नब्बे के दशक के उत्तरार्ध से जावा को नहीं देखा है, सबसे अधिक संभावना है कि एक .net समाधान - .net शब्दावली और डिज़ाइन पैटर्न का उपयोग किया जाए - भले ही जावा (या RoR आदि) बेहतर होगा कि समस्या ठीक हो। बाद में किसी अन्य तकनीक में इस तरह के डिजाइन को लागू करना अपेक्षाकृत कठिन है।

इसलिए, मुझे लगता है कि एक विश्लेषक को अज्ञेय होना चाहिए, जब प्रौद्योगिकी अभी तक चयनित नहीं हुई है, लेकिन उन मामलों में अनुभव किया गया है जहां पसंद पहले ही बनाई जा चुकी है।

Comments

पैटर्न भाषा-अज्ञेय डिजाइन नहीं कर रहे हैं?

— मार्को-फिसेट

वे आमतौर पर एक विशिष्ट भाषा से बंधे नहीं होते हैं, लेकिन कुछ प्रौद्योगिकी स्टैक उन्हें दूसरों की तुलना में लागू करने में आसान बना सकते हैं। ASP.net MVC के साथ बनाया गया एक डिज़ाइन सादा PHP या Oracle अनुप्रयोग एक्सप्रेस में लागू करने के लिए बोझिल हो सकता है।

— user281377