एक सॉफ्टवेयर विकास विचार या तकनीक का एक अच्छा उदाहरण क्या है जो एक विफलता थी?

Question

विशेष रूप से ऐसे कौन से उदाहरण हैं जहां जनता के विचार जहां गलत हैं। लोगों ने विचारों को पहली जगह पर क्यों लटकाया? और विचारों को खारिज क्यों किया गया? या शायद विचार अभी भी जीवित हैं और अच्छी तरह से और यदि ऐसा है तो क्यों?

उदाहरण के लिए, मैं सॉफ़्टवेयर के घटकों के बीच संचार की समस्या को हल करने के प्रयास के रूप में कोरा (और अन्य समान तकनीकों) का वर्णन कर सकता हूं । कई लोगों ने महसूस किया कि विभिन्न घटकों के बीच अनुबंध को परिभाषित करना आवश्यक है। अंततः, HTTP + JSON ने जनता और अन्य विभिन्न RPC तंत्रों के लिए समस्या को हल कर दिया जैसे कि थ्रिफ्ट और प्रोटो-बफ़्स पॉप अप हो गए हैं।

Comments

EXXXXXXXXXXXXXXXXXTREEEEEEEEEEEMEE प्रोग्रामिंग देखें ...

— crasic

कोई "जनता के विचार" नहीं हैं, बस ऐसे विचार जो लोकप्रिय हो गए हैं, और मुझे कोई विचार नहीं है कि कुछ ऐसा कैसे किया जाए जो लंबे समय तक उपयोग में हो, जो कि बड़े पैमाने पर लोकप्रिय होने के लिए "बस गलत" हो सकता है, जैसा कि जाहिर है कुछ समस्याओं को हल करना चाहिए या इसे हर किसी के द्वारा तुरंत छोड़ दिया जाएगा जो इसे आजमाता है।

— माइकल बोर्गवर्ड

CORBA कोई विफलता नहीं है .. यह अभी भी उपयोग में है

— oenone

@ नहीं, यह इस अर्थ में एक विफलता है कि इसने सामान्य रूप से अंतर-समस्या को हल करने के अपने मूल वादे को पूरा नहीं किया, और यह अब एक आला तकनीक है।

— Péter Török

HTTP JSON ने वेबसर्विस के साथ मुद्दों को हल किया लेकिन वास्तव में सॉफ्टवेयर्स के दूसरे क्षेत्र के साथ नहीं!

— सैराट

Answer 1

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

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

अंततः, HTTP + JSON ने जनता के लिए समस्या का समाधान किया

कम से कम किसी ऐसे व्यक्ति के लिए, जिसने समान "अंतिम समाधान" के एक जोड़े को नहीं देखा है और अंततः गिर गया ... यह ध्यान रखना अच्छा है कि उसके समय में कोरबा के बारे में इसी तरह की भावना थी;;

मुझे लगता है कि यह कोरा के उदय और पतन से उद्धृत करने के लिए उपयुक्त है :

CORBA का इतिहास वह है जिसे कंप्यूटिंग उद्योग ने कई बार देखा है, और यह संभावना है कि वर्तमान मिडलवेयर प्रयासों, विशेष रूप से वेब सेवाओं, एक समान इतिहास को फिर से सक्रिय करेगा। [...]

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

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

---

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

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

Comments

उस लिंक के माध्यम से पढ़ना: प्रिय भगवान, कॉरबा भयानक रहा होगा यदि V1 EJBs ने इसे दबा दिया क्योंकि वे सरल थे ...

— माइकल बोर्गवर्ड

उत्पाद Michi Henning को विकसित करने के लिए चला गया है CORBA की बहुत सारी कमियां।

— ब्लरफ्ल

Answer 2

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

इस पाठ के बाद यह चित्र है:

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

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

लोग पहले ही झरने की ओर क्यों लपके, मुझे नहीं पता। मुझे लगता है कि वे जोखिम लेना और विफलता को आमंत्रित करना पसंद करते हैं।

Comments

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

— मेपल_शफ्ट

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

— थॉमस ओवेन्स

झरना मॉडल पूरी तरह से गलत नहीं है: यह एक सॉफ्टवेयर परियोजना को विकसित करने में सामान्य चरणों की सही पहचान करता है और उन्हें तार्किक रूप से आदेश देता है। यह स्वीकार करने में विफल रहता है कि तथ्य यह है कि एक सॉफ्टवेयर परियोजना को iteratively और modularly लिखा जा सकता है, और इस तरह, जलप्रपात मॉडल के चरणों का वर्णन व्यक्तिगत पुनरावृत्तियों और / या पूरे सिस्टम के घटकों के लिए विभिन्न कॉन्फ़िगरेशन में किया जा सकता है।

— tadmers

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

— maple_shaft

"लोगों ने पहले जलप्रपात पर कब्जा क्यों किया, मुझे नहीं पता। मुझे लगता है कि वे जोखिम लेना और विफलता को आमंत्रित करना पसंद करते हैं।" IMHO यह बिल्कुल विपरीत है। सामान्य रूप से लोग यह महसूस करना पसंद करते हैं कि वे स्थिति के नियंत्रण में हैं, और आरेख और विस्तृत कार्यप्रणाली उन्हें सुरक्षा की भावना देती है। चूंकि उन प्रक्रियाओं और चार्ट ने उन्हें बहुत सारे अन्य क्षेत्रों में पहले मदद की है, इसलिए वे मानते हैं (इस मामले में गलत तरीके से) कि यह SW विकास में भी उसी तरह से काम करेगा ...

— Péter Török

Answer 3

एक उच्च अमूर्त स्तर, या स्वचालित प्रोग्रामिंग से कोड की स्वचालित पीढ़ी ।

विकिपीडिया लेख ऐतिहासिक जानकारी में कुछ कमी है, लेकिन यह प्रबंधकों का एक सपना रहा है क्योंकि प्रोग्रामर कंप्यूटर की तुलना में अधिक महंगे हो गए हैं।

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

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

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

प्रोग्रामर की लागत को कम करने के लिए शेष स्थानों के लिए प्रोग्रामिंग प्रोग्रामिंग कुछ तरीकों में से एक है। आउटसोर्सिंग की समस्याओं में संचार समस्याएं और विनिर्देशन समस्याएं शामिल हैं।

Comments

इसके अलावा, SQL और Visual Basic, दोनों को गैर-प्रोग्रामर को प्रोग्राम लिखने की अनुमति देने के लिए विज्ञापित किया गया था।

— सीन मैकमिलन

Answer 4

औपचारिक तरीके

एक बार, यह प्रस्तावित किया गया था कि सॉफ्टवेयर को सही साबित किया जा सकता है। (यह विचार किया जा रहा है कि परीक्षण यह नहीं दिखा सकता है कि कोई त्रुटि नहीं है, लेकिन प्रमाण सक्षम होंगे।) दुर्भाग्य से, एक कार्यक्रम के लिए एक प्रमाण तैयार करने में कुछ बड़ी कमियां हैं:

• यह प्रोग्राम लिखने की तुलना में अधिक कठिन और समय लेने वाला है।
• यह पूरे कार्यक्रम को कवर करने के लिए है, जिसका अर्थ है कि आपको किसी भी पुस्तकालय, ओएस, आदि के लिए सबूत की आवश्यकता है ...
• यह बग की अनुपस्थिति को साबित नहीं करता है, क्योंकि ये कीड़े दुर्घटना के कारण हो सकते हैं।

70 के दशक में यह अवधारणा बहुत लोकप्रिय थी।

लिंकेज: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods

Comments

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

— थॉमस ओवेन्स

@ थोमस: एक अच्छी बात। और औपचारिक तरीके उन परियोजनाओं को अपनाते हैं जिनमें मृत्यु रेखा पर होती है। लेकिन वे निश्चित रूप से बग-मुक्त सॉफ्टवेयर के लिए चांदी की गोली नहीं थे।

— शॉन मैकमिलन

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

— थॉमस ओवेन्स