एक समस्या को संबोधित करने के लिए प्रोग्रामिंग प्रतिमान की पसंद के लिए अनुभवजन्य साक्ष्य

Question

C2 विकी में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए अनुभवजन्य साक्ष्य की चर्चा है जो मूल रूप से निष्कर्ष निकालती है कि प्राधिकरण से अपील के अलावा कोई नहीं है। यह आखिरी बार 2008 में संपादित किया गया था। चर्चा यहाँ यह प्रतीत होती है: OO पुरानी है , जब कार्यात्मक प्रोग्रामिंग एक बुरा विकल्प है और AOP के फायदे और नुकसान सभी सवालों के साक्ष्य पर निर्भरता के बिना योगदानकर्ताओं की राय के साथ उत्तर दिए गए हैं।

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

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

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

दूसरे शब्दों में: कुछ लोग कहते हैं कि "OO बेहतर लचीलापन देता है" या "कार्यात्मक कार्यक्रमों में कम कीड़े होते हैं" - (मैं जो पूछ रहा हूं उसका कुछ हिस्सा) इसका प्रमाण है। बाकी लोग इसके खिलाफ सबूत मांग रहे हैं, या उन मान्यताओं के तहत, जिनके बारे में ये कथन सत्य हैं, या सबूत दिखाते हैं कि ये विचार महत्वपूर्ण नहीं हैं। इस बात पर बहुत सारी राय है कि एक प्रतिमान दूसरे से बेहतर क्यों है; क्या इनमें से किसी के पीछे कोई उद्देश्य है?

Comments

साक्ष्य-आधारित सॉफ्टवेयर इंजीनियरिंग के लिए वेब खोज काफी लिंक दिखाती है

— gnat

@gnat EBSE साहित्य को व्यवस्थित रूप से प्रस्तुत करने और सामान्य निष्कर्ष निकालने के बारे में है कि हम अभ्यास को कैसे बेहतर बना सकते हैं। मेरा सवाल यह है कि क्या साहित्य मौजूद है; चाहे उत्पादक समीक्षा के लिए पर्याप्त हो या मेटानालिसिस उत्पादक होने के लिए।

Answer 1

पिछले लेने के लिए, इस उत्तर का संशोधन 1 देखें । हालाँकि, प्रश्न के लिए टिप्पणियाँ और संपादन आगे स्पष्ट करते हैं कि प्रश्न क्या मांग रहा है और मुझे अधिक स्पष्ट होने की अनुमति देता है।

हां, साक्ष्य आधारित सॉफ्टवेयर इंजीनियरिंग (ईबीएसई) एक चीज है। EBSE डेटाबेस की दिशा में कुछ प्रयास प्रतीत होते हैं, जैसे कि डरहम यूनिवर्सिटी और SEED में एक, जिसे कैल पॉली में एक प्रोफेसर द्वारा शुरू किया गया था । इन सभी प्रयासों के साथ-साथ उन कई पत्रों पर चर्चा हुई जो IEEE Xplore सर्वर या ACMST लाइब्रेरी के माध्यम से मिल सकते हैं(सदस्यता या दोनों में कई कागजात के लिए आवश्यक खरीद), साक्ष्य-आधारित दवा पर आधारित हैं। वे प्रकाशित अनुभवजन्य (अवलोकन और प्रयोग) डेटा की साहित्य समीक्षा प्रदान करते हैं। वास्तव में, किसी भी प्रकाशन पर खोज स्ट्रिंग में "साहित्य की समीक्षा" सहित अधिकांश विषयों पर जानकारी मिलती है - एसीएम पर 14000 से अधिक हिट और आईईईई डेटाबेस पर 1000 से अधिक (जब केवल कंप्यूटिंग विषयों तक सीमित है)।

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

इसलिए, यह अवधारणा सॉफ्टवेयर इंजीनियरिंग में मौजूद है। एकेडेमिया साक्ष्य-आधारित अवधारणा से अवगत है और इसे सॉफ्टवेयर इंजीनियरिंग में सफलतापूर्वक लागू कर सकता है।

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

एक प्रतिमान चुनने के लिए निश्चित रूप से "क्रैंक टर्न" समाधान नहीं है।

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

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

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

एक चिकित्सक के रूप में, जब मैं उपयोग करने के लिए तकनीकों को चुनने में शामिल होता हूं, तो मैं सर्वोत्तम संभव उपकरणों की पहचान करने की कोशिश करता हूं। लेकिन फिर मैं अपने आप को विवश करता हूं कि मेरे पास जो टीम है, वह अच्छी तरह से जानता है। अपने पिछले उदाहरण पर वापस जाऊं, अगर मेरे पास C ++ में समवर्ती अनुप्रयोगों के निर्माण में अच्छी तरह से काम करने वाली टीम है और हास्केल में कोई अनुभव नहीं है, तो हास्केल में सिस्टम के निर्माण का प्रस्ताव करने का कोई मतलब नहीं है क्योंकि मैं संभावना नहीं बना पाऊंगा शेड्यूल और बजट की कमी, और टूलचिन में अनुभव की कमी के कारण मेरी गुणवत्ता में कमी होगी।

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

यदि आप इस बात का पता लगाना चाहते हैं कि कार्यात्मक प्रोग्रामिंग में ऑब्जेक्ट-ओरिएंटेशन कैसे पुन: प्रयोज्य या दोषों को संबोधित करता है - तो आप आसानी से उन पर प्रकाशन पाएंगे। हालांकि, मुझे ऐसा प्रकाशन नहीं मिला (और न ही मैं किसी भी प्रकार के विश्वास में डालूंगा) एक प्रकाशन जो वास्तविक दुनिया सॉफ्टवेयर इंजीनियरिंग परियोजनाओं की व्यापक रेंज में प्रतिमान चयन को प्रभावी ढंग से संबोधित करने में सक्षम था।

Comments

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

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

— थॉमस ओवेन्स

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

— संकट

@ क्रिस मुझे विश्वास नहीं है कि वे विज्ञान के लिए अपारदर्शी हैं। हालांकि, मेरा मानना ​​है कि कुछ चीजें हैं जो आप तक पहुँचती हैं, जैसा कि ग्राहम सवाल में कहते हैं, अनुसंधान के लिए "बहुत सी बातें और धारणाएं" जोड़ें, यह अब चिकित्सकों के लिए उपयोगी नहीं है। उस समय, एक व्यावहारिक, इन-ट्रेंच परिप्रेक्ष्य से, यह इतिहास और अनुभव पर अपने निर्णयों को आधार बनाने के लिए अधिक प्रभावी है। अच्छा, कठोर, मान्य डेटा होना बहुत अच्छी बात है। लेकिन एक ऐसा बिंदु आता है जब इसे प्राप्त करना बहुत कठिन होता है या यह केवल एक बहुत ही विशिष्ट स्थिति में मान्य होता है कि यह उद्योग के लिए उपयोगी नहीं है।

— थॉमस ओवेन्स

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

— संकट

Answer 2

मैं एरिक एस रेमंड द्वारा द आर्ट ऑफ यूनिक्स प्रोग्रामिंग पढ़ रहा हूं । हमारे पास अब दी गई चीजों के बारे में कुछ बहुत ही दिलचस्प ऐतिहासिक अंतर्दृष्टि हैं। वह IEEE सॉफ्टवेयर से कुछ अच्छे अध्ययनों का हवाला देता है जो दोष घनत्व जैसे अनुभवजन्य साक्ष्य का उपयोग करते हैं। यदि आप अकादमिक शैली के अध्ययन की तलाश कर रहे हैं तो यह एक अच्छा स्रोत हो सकता है।

यहां तक ​​कि कार्यों का उपयोग करते हुए मॉड्यूलाइज़ करने जैसी तकनीकें हमेशा सामान्य व्यवहार नहीं थीं। पुस्तक के अब तक के मेरे पसंदीदा उद्धरणों में से एक:

डेनिस रिची ने सभी को बताकर और मोड्यूलरिटी को प्रोत्साहित किया कि फ़ंक्शन कॉल वास्तव में, सी में बहुत सस्ते थे। हर कोई छोटे कार्यों को लिखना और मॉड्यूलर करना शुरू कर दिया। वर्षों बाद हमें पता चला कि PDP-11 पर फ़ंक्शन कॉल अभी भी महंगे थे, और VAX कोड अक्सर CALLS निर्देश में अपने समय का 50% खर्च कर रहा था। डेनिस ने हमसे झूठ बोला था! मगर बहुत देर हो चुकी थी; हम सभी चौंक गए थे ...

- स्टीव जॉनसन

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

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

इसलिए मुझे लगता है कि OOP अपनी कमियों के बावजूद लोकप्रियता में शीर्ष पर पहुंच गया है। यह इतना प्रतिबंधात्मक नहीं है कि यह सबसे प्रतिभाशाली लोगों को शौक देता है, लेकिन इसकी संरचना कम से कम प्रतिभाशाली लोगों पर अच्छे डिजाइन सिद्धांतों को संप्रेषित करने और लागू करने का एक संक्षिप्त तरीका प्रदान करती है।

हमारे काम की लाइन में हमारे पास अकेले तकनीकी गुणों के आधार पर किसी समाधान का मूल्यांकन करने की प्रवृत्ति है। एक सफल प्रयास के समीकरण के मानवीय पक्ष के लिए भी जिम्मेदार है।

Comments

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

+1, "दूसरी समस्या यह है कि 50% डेवलपर्स के पास औसत प्रोग्रामिंग प्रतिभा से नीचे है।" यह सजा मेरे लिए राहत की बात है। यह मैंने कोशिश की कई गोलियों से बेहतर है :)

— NoChance

Answer 3

प्रोग्रामिंग प्रतियोगिताएं हैं जो एक कंप्यूटर ग्रेडिंग सिस्टम का उपयोग करती हैं और आपको विभिन्न भाषाओं में लिखने और सभी प्रकार के परिणामों और चीजों को पोस्ट करने की अनुमति देती हैं। मुझे यकीन है कि उनके पास आपके लिए अच्छा डेटा है। यहां 8 की सूची दी गई है: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-n/

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

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

मुझे लगता है कि मैं जो कह रहा हूं वह यह है कि वास्तविक दुनिया के अनुप्रयोगों के लिए, भाषा या टूल की सार्थक तरीके से तुलना करना बहुत मुश्किल है - पुराने सेब और संतरे का मुद्दा। सौभाग्य! मुझे यह देखना अच्छा लगेगा कि आपको क्या पता है।

Answer 4

मैं 30+ वर्षों से सॉफ़्टवेयर विकसित करने के विभिन्न तरीकों का अध्ययन कर रहा हूँ। प्रतिमान चुनने पर अच्छे प्रकाशित प्रमाणों की कमी है।

मैंने एक बड़ी खोज योग्य ASCII ग्रंथ सूची तैयार की। इसमें बहुत सारे IEEE और ACM पेपर और लेख शामिल हैं। मैं प्रदान किए गए सबूत के प्रकार के साथ आइटम को टैग करता हूं। यहाँ सबसे आम टैग हैं:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

अब PARADIGM को सर्च करें और टैग को गिनें

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

यदि आप गहरी खुदाई करना चाहते हैं, तो http://cse.csusb.edu/dick/lab.html और मुझे उम्मीद है कि यह मदद करेगा ...

Answer 5

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

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

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

तो मैं जो जवाब दे रहा हूं वह "नहीं" है, जो सबूत मैं देख रहा हूं वह शायद मौजूद नहीं है। मुझे जो कुछ पता है, जो शांत और विशेषज्ञ की राय है, उसके मौजूदा लोकप्रिय मानदंडों के आधार पर मुझे अपना प्रतिमान चुनना चाहिए।

Comments

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

— स्टीवन ए लोव

स्टीवन: ईबीएसई के पीछे प्रेरणा का एक हिस्सा "मैं निम्नलिखित समस्याओं का अनुमान लगा सकता हूं, इसलिए मैं अपने स्वयं के गुणों पर परिणामों का विश्लेषण करने के लिए आपके समाधान के किसी भी अवसर को अस्वीकार कर दूंगा"। इसके अमूर्त की तुलना में बहुत अधिक कागज है।

मैं आपके उत्साह की सराहना करता हूं। चिकित्सा विज्ञान और सॉफ्टवेयर विकास मौलिक रूप से विभिन्न विषयों हैं। जबकि सादृश्य दिलचस्प है, यह शायद ही ज़मीनी है। पूरा पेपर यहाँ उपलब्ध है labada.inf.utfsm.cl/~gvaldes/ESE/docs/… धारा 5 सार में उल्लिखित प्रतिबाधा बेमेल को दर्शाता है। चिकित्सा तकनीकों का एक अधिक प्रत्यक्ष मानचित्रण मौजूदा सिस्टम को डीबग करना होगा, नए निर्माण नहीं। ;) यदि आप बेहतर उत्पादों का निर्माण करना चाहते हैं, तो बेहतर टीमों का निर्माण करें। उपकरण (cf Peopleware) की तुलना में लोग कहीं अधिक महत्वपूर्ण हैं

— स्टीवन ए। लोव

परिशिष्ट: EBSE साइट में कुछ उपयोगी जानकारी है, dur.ac.uk/ebse/evidence.php एसई क्षेत्र के लिए उन लोगों के लिए विशेष रूप से उपयोगी होगी - लेकिन नमक के एक ब्लॉक के साथ सर्वेक्षण करें, क्योंकि (1) उपलब्ध सबूत बहुत कम है और (2) औसत परिणाम अत्यधिक विशिष्ट कौशल और योग्यता के साथ विशिष्ट व्यक्तियों की आपकी टीम के प्रदर्शन के लिए प्रासंगिक नहीं हो सकते हैं।

— स्टीवन ए। लोव

Answer 6

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

अपडेट करें

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

Comments

मैं कैसे चुनूं कि क्या जावा प्रोग्रामर की टीम, या सी प्रोग्रामर की टीम को नियुक्त किया जाए? क्या मुझे उन्हें क्लोज़र में वापस लेना चाहिए? एक बार जब मैंने अपना एल्गोरिथ्म चुना है, तो "सर्वश्रेष्ठ" के दिए गए मूल्यों के लिए, सॉफ़्टवेयर समाधान में इसे एनकैप्सुलेट करने का "आर्किटेक्चर" सबसे अच्छा तरीका क्या है?

@GrahamLee मेरा अपडेट देखें

— Woot4Moo

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

Answer 7

विभिन्न प्रतिमान विभिन्न समाधानों की ओर ले जाते हैं। कौन सा फिट है 'सबसे अच्छा' काफी हद तक निर्भर करता है:

• समाधान
• विकास टीम
• परिचालन वातावरण

मुझे इस तरह के कोई निश्चित अध्ययन का पता नहीं है, और यहां तक ​​कि अगर कोई ऐसा था जिस पर मुझे भरोसा नहीं होता।

वह आर्किटेक्ट का काम है।

अध्ययन के संभावित अप्रासंगिक निष्कर्षों के साथ आर्किटेक्ट के ज्ञान को प्रतिस्थापित करना आपदा के लिए एक नुस्खा है।

नोट: एक टिप्पणी में "एल्गोरिथ्म" पर निर्णय लेने और फिर भाषा चुनने का उल्लेख है। एल्गोरिदम प्रक्रियात्मक भाषाओं के लिए केंद्रीय संरचनात्मक तंत्र हैं। ऑब्जेक्ट-ओरिएंटेड भाषाएं सहयोग / संचार के वर्गों और पैटर्न पर ध्यान केंद्रित करती हैं। यदि आप आश्वस्त हैं (वास्तुकार के रूप में) कि एल्गोरिथम-केंद्रित समाधान 'सर्वोत्तम' है, तो प्रक्रियात्मक या कार्यात्मक भाषाओं के साथ रहें।

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

Comments

तो क्या यह वास्तुविद् के दायरे से बाहर है कि पूर्व के काम की तलाश करें, जिस पर वह अपनी राय बनाए? शायद नहीं - इसलिए इस तरह के परिणाम पाए जा सकते हैं या नहीं का सवाल है।

यदि एक उचित प्रयोगात्मक विधि के साथ एक निश्चित अध्ययन था तो अध्ययन के परिणाम दिलचस्प हो सकते हैं; जैसा कि यह कहा गया है कि यह उत्तर बताता है कि कोई भी अध्ययन बेकार पद्धति है, जो मेरी पसंद

— jk के

@ शब्द: वास्तव में निश्चित अध्ययन के परिणामों पर भरोसा नहीं करने के लिए शब्द 'अंधविश्वास' है। शायद आपका जो मतलब है वह यह है कि आप विश्वास नहीं करते कि एसई में कभी भी निश्चित अध्ययन हो सकते हैं (कौन सा कथन स्वयं स्पष्ट रूप से प्रमाण के एक बड़े, अच्छी तरह से समर्थित शरीर की आवश्यकता होगी)।

— क्रिस

एक सॉफ्टवेयर पद्धति की गुणवत्ता यह है कि यह स्थानीय मानव की जरूरत से कितनी अच्छी तरह मेल खाती है। सामान्य तौर पर, यह भौतिकी (स्कूटी) के नियमों से बाध्य नहीं है। 'सॉफ्टवेयर ’से पहले यह एक लंबा समय होगा [अनुशासन] अपने अपरिवर्तनीय मौलिक कानूनों को भंग करने का प्रबंधन करता है। उदाहरण के लिए "सॉफ्टवेयर क्वालिटी मेट्रिक्स: तीन हानिकारक मेट्रिक्स और दो सहायक मेट्रिक्स" देख में ppi-int.com/newsletter/SyEN-046.php#feature और ppi-int.com/newsletter/SyEN-047.php#feature

— फिलिप ओक्ले

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

— स्टीवन ए। लोव