आईटी उद्योग अन्य उद्योगों की तरह बड़ी, दोषरहित परियोजनाओं को जल्दी से क्यों नहीं दे सकता है?

Question

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

उदाहरण के लिए, Airbus A380 "औपचारिक रूप से 19 दिसंबर, 2000 को लॉन्च किया गया" और "मार्च की शुरुआत, 2005" में , विमान का परीक्षण पहले ही किया जा चुका था। वही विशाल तेल टैंकरों, गगनचुंबी इमारतों आदि के लिए जाता है।

सॉफ्टवेयर उद्योग में देरी की तुलना करने पर, मैं यह सोचकर मदद नहीं कर सकता कि अधिकांश आईटी परियोजनाएं इतनी धीमी या अधिक सटीक क्यों हैं, वे पर्याप्त और दोषरहित क्यों नहीं हो सकते हैं, एक ही पैमाने पर, पर्याप्त लोगों को दिया जाता है?

---

एयरबस ए 380 जैसी परियोजनाएं दोनों मौजूद हैं:

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

• सामान्य रूप से मानव संसाधन और प्रबंधन से संबंधित जोखिम: परियोजना के बीच में छोड़ने वाले लोग, एक व्यक्ति तक पहुंचने में असमर्थता क्योंकि वह छुट्टी पर है, सामान्य मानव त्रुटियां, आदि।

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

जब सॉफ्टवेयर विकास की बात आती है, तो प्रोजेक्ट शायद ही बड़े और जटिल होते हैं जैसे कि एयरलाइनर (तकनीकी रूप से और प्रबंधन के संदर्भ में), और वास्तविक दुनिया से थोड़ा कम जोखिम वाले जोखिम होते हैं।

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

जो अभी भी वितरित किए गए हैं, उनमें अक्सर बहुत सारे बग हो सकते हैं, जिनमें लगातार सर्विस पैक और नियमित अपडेट की आवश्यकता होती है (कल्पना करें कि मूल उत्पाद में बग्स को पैच करने और विमान को दुर्घटनाग्रस्त होने से बचाने के लिए प्रति सप्ताह दो बार एयरबस ए 380 पर "अपडेट स्थापित करना")।

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

Comments

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

— नोल्डोरिन

किसी ऐसे व्यक्ति को ढूंढें जो वास्तव में उन अन्य उद्योगों में से किसी में काम करता है (लेकिन पीआर में नहीं) और उनसे "बड़ी दोषरहित परियोजनाओं" के बारे में पूछें। मैं वस्तुतः गारंटी दे सकता हूँ कि आप दर्द भरी हँसी कमाएँगे।

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

एक सॉफ्टवेयर परियोजना की प्राप्ति में कुछ सेकंड या मिनट लगते हैं; यह तब होता है जब आप अपने IDE में "संकलन" पर क्लिक करते हैं। दूसरी ओर, प्रोग्रामिंग डिजाइन है । A380 को डिजाइन करने में कितना समय लगा?

— Ant

वह टीवी कार्यक्रम एक प्रचार है। वे केवल सफल परियोजनाओं का प्रसारण करते हैं। कोई भी चैनल दर्शकों का ध्यान आकर्षित करने के लिए कार्यक्रम बनाएगा।

— पांडु

प्रति सप्ताह दो बार हर एयरबस ए 380 पर "अपडेट" इंस्टॉल करने की कल्पना करें ... 'कल्पना कीजिए कि दुश्मन रोबोट लगातार कमजोरियों के लिए विमान की जांच कर रहे हैं जबकि अप्रशिक्षित पायलट यादृच्छिक पर बटन दबाते हैं। मुझे यकीन है कि आपको नियमित पैच की आवश्यकता होगी।

— नेथन लॉन्ग

Answer 1

एड योरडन की डेथ मार्च इन मेटा प्रकार के कई सवालों को छूती है।

सामान्य तौर पर, सॉफ्टवेयर उद्योग में निम्नलिखित में बहुत कमी होती है, जो बड़ी परियोजनाओं के रास्ते में आती है।

• मानकीकरण और कार्य मद का टूटना।

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

• सफल, समान परियोजनाओं का एक बड़ा निकाय। A380 पहला बड़ा हवाई जहाज नहीं था जिसे एयरबस ने बनाया था। वहाँ बहुत सारे बड़े सॉफ्टवेयर अनुप्रयोग हैं, लेकिन उनमें से कई किसी न किसी पहलू में नाटकीय रूप से पीड़ित हुए हैं और "सफल" कहलाने के करीब नहीं आएंगे।

• डिजाइनरों और बिल्डरों का एक बड़ा निकाय जिन्होंने कई समान और सफल परियोजनाओं पर काम किया है। सफल परियोजना के मुद्दे से संबंधित, मानव प्रतिभा जो वहाँ रही है, नहीं किया है कि चीजों को दोहराने की दृष्टि से बहुत मुश्किल बनाता है।

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

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

• क्यूए / क्यूसी पर जोर नहीं दिया जाता है क्योंकि यह बड़ी परियोजनाओं के लिए हो सकता है या होना चाहिए। यह घटकों के बीच शिथिल इंटरफेस होने पर वापस चला जाता है, और घटकों को कैसे काम करना चाहिए, इसके लिए कठोर विनिर्देशों का न होना। यह ढीलापन अनपेक्षित परिणामों के लिए और बगों में रेंगने की अनुमति देता है।

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

मेरा मतलब यह नहीं है कि सभी नकारात्मक हैं, और मुझे लगता है कि सॉफ्टवेयर उद्योग ने महत्वपूर्ण प्रगति की है जहाँ से हम बने हैं। इस तरह के मंचों और अन्य लोगों ने वास्तव में बातचीत और डिजाइन सिद्धांतों की चर्चा को बढ़ावा देने में मदद की है। सॉफ्टवेयर इंजीनियरों के लिए "बेसलाइन" ज्ञान को मानकीकृत करने के लिए काम करने वाले संगठन हैं। सुधार के लिए निश्चित रूप से जगह है, लेकिन मुझे लगता है कि उद्योग ने काफी कम समय में एक लंबा सफर तय किया है।

Comments

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

— आर्सेनी मूरज़ेंको

+1 लेकिन क्या मैं सिर्फ इतना जोड़ सकता हूं कि चूंकि सॉफ्टवेयर मन के दायरे में मौजूद है, इसमें लगभग असीम संभावनाएं हैं, जबकि प्रत्येक निर्मित प्रत्येक विमान को वास्तविकता की परिमित आवश्यकताओं के अनुरूप होना चाहिए।

— स्पेंसर रथबुन

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

— बिल के

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

— माइकल ब्राउन

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

— माइकल ब्राउन

Answer 2

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

अन्य उद्योगों में कई डिजाइन या तो मूल रूप से अनुमानित लागत की तुलना में अधिक समय लेते हैं, या कभी पूरा नहीं होते हैं। जाना पहचाना?

जब हम सॉफ्टवेयर की योजना बना रहे हैं तो हम क्या कर रहे हैं? ठीक है, हम अभी भी डिजाइन कर रहे हैं, लेकिन पहले के चरण में।

सॉफ्टवेयर में, नोट की कोई निर्माण रेखा नहीं है। अंतिम घटक का निर्माण (तुलनात्मक रूप से) सस्ता है, और उस अंतिम उत्पाद की प्रतिकृति पूर्ण और प्रभावी रूप से दोनों मुक्त है - आप बिल्ड कलाकृतियों की नकल करते हैं।

Comments

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

— टीमबॉ

एक हजार बार यह। यहां तक ​​कि प्रश्न की अनुसूची लिंक से पता चलता है कि परियोजना वास्तव में 1988 से विकास में थी। स्रोत कोड डिजाइन है: developerdotstar.com/mag/articles/reeves_design.html

— pkh

कई बड़े प्रोजेक्ट जैसे एफ -35, हबल टेलीस्कोप आदि विकास के सॉफ्टवेयर पक्ष की वजह से देर से आए। हबल वास्तव में सालों तक भंडारण में रहा क्योंकि सॉफ्टवेयर तैयार नहीं था।

— 2

@ मैलेन: वास्तविक दुनिया में यह इस तरह से काम करता है। एक शेड्यूल सेट किया जाता है जब हार्डवेयर को करना होता है और सॉफ्टवेयर को माना जाता है। हार्डवेयर डिजाइनर सॉफ्टवेयर टीम को एक ICD प्रदान करते हैं, ताकि स्व टीम हार्डवेयर के बिना अपना कोड लिख सके। हार्डवेयर अपने शेड्यूल को बहुत आगे खिसका देता है और hw मुद्दों के आसपास काम करने के लिए अपने इंटरफेस को बदल देता है, अक्सर स्वेट टीम को सूचित किए बिना। अंत में, काम करता है और जिस तरह से दिया जाता है, देर से पहुंचता है। बेशक अप्रत्याशित hw "सुविधाओं" के असंख्य के कारण sw काम नहीं करता है। क्योंकि हार्डवेयर समस्याओं को ठीक करने के लिए यह सस्ता है ...

— डंक

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

— डंक

Answer 3

कुछ आंकड़े बताने के लिए:

1. कार्यान्वयन शुरू होने के बाद आवश्यकताओं में बदलाव ; उदाहरण के लिए जब पहली एयरबस ए 380 को कारखाने में बनाया जाना शुरू हुआ, तो मुझे विश्वास नहीं हो रहा था कि अगर कोई 200 से अधिक सीटें चाहता है, तो उन्हें वहां रखा जाएगा; लेकिन एक बड़े सॉफ्टवेयर प्रोजेक्ट में, प्रोग्रामर द्वारा विकास शुरू करने के बाद भी 5 और प्रकार के उपयोगकर्ताओं को जोड़ा जा सकता है।
2. जटिलता - बड़े सॉफ्टवेयर प्रोजेक्ट बेहद जटिल हैं; शायद सबसे जटिल परियोजनाएं मानव प्रकार की डिजाइन और विकसित;
3. वास्तुकला और डिजाइन चरण में पर्याप्त संसाधन खर्च नहीं किए जाते हैं ;
4. फील्ड अपरिपक्वता - सॉफ्टवेयर इंजीनियरिंग अन्य इंजीनियरिंग बहनों की तुलना में अपेक्षाकृत युवा अनुशासन है; इसके दो निहितार्थ हैं: क) इतने सारे आंकड़े और अच्छे व्यवहार नहीं; बी) इतने सारे अनुभवी विशेषज्ञ नहीं;
5. गणितीय प्रमाण का अभाव - ज्यादातर मामलों में गणितीय औपचारिक तरीकों का उपयोग यह साबित करने के लिए नहीं किया जाता है कि सॉफ़्टवेयर का एक टुकड़ा आवश्यकतानुसार काम करता है; इसके बजाय परीक्षण का उपयोग किया जाता है। यह अन्य इंजीनियरिंग क्षेत्रों में सच है जो गणित पर अधिक निर्भर करता है; इसका कारण जटिलता है;
6. रश - कई प्रबंधकों को अस्वीकार्य समय सीमा है; इसलिए कोड की गुणवत्ता को अंतिम समय सीमा के कारण रखा गया है।

प्रश्न का कड़ाई से जवाब देना - मेरा मानना ​​है कि दूसरों को प्रोग्रामर से बहुत अधिक उम्मीदें हैं (विशेष रूप से डिलीवरी के समय में) और यह बिल्कुल समझ में नहीं आता है कि बड़े सॉफ्टवेयर की प्रोग्रामिंग कितनी कठिन है।

Comments

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

— tdammers

tdammers, ऐसे उपकरण हैं जो आपको एक ही बार में लिखने में मदद कर सकते हैं: Coq एक प्रमाणित Coq प्रोग्राम से OCaml या स्कीम में प्रोग्राम निकालने के लिए "प्रोग्राम निष्कर्षण" का समर्थन करता है।

— जफ

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

— आलसी DBA

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

— रेयान

# 1 आपकी सूची में सबसे महत्वपूर्ण IMO है, मैं इसमें दो और चीजें जोड़ूंगा: -बड़े बदलाव थोड़े समय में किए जा सकते हैं (उदाहरण के लिए 'संचार प्रोटोकॉल को स्विच करने देता है!'), जो सामान को नहीं तोड़ेंगे। अल्पावधि में, लेकिन इनमें से कई लंबी अवधि में परियोजना का प्रबंधन करने के लिए बहुत कठिन बनाते हैं। - वातावरण में परिवर्तन जहां सॉफ्टवेयर चलता है, थोड़े समय में काफी बदल सकता है। जबकि एक हवाई जहाज के लिए मूल परिसर समान रहेगा (तूफानों में उड़ना चाहिए, ठोस रनवे पर उतरना चाहिए, ..), एक सॉफ्टवेयर पूरी तरह से टूट सकता है, अगर ओएस का नया संस्करण उदाहरण के लिए बाहर आता है।

— sydd

Answer 4

प्रश्न का आधार थोड़ा त्रुटिपूर्ण है। A380 और बोइंग 787 दोनों को साल के अंत में वितरित किया गया था।

A380 के मामले में एयरबस की फ्रांसीसी और जर्मन इकाइयों द्वारा CATIA डिजाइन सॉफ्टवेयर के विभिन्न और थोड़े असंगत संस्करणों का उपयोग करने के कारण बहुत देरी हुई । यह असंगत रूप से वायरिंग हार्नेस के रूप में प्रकट हुआ जो हवाई जहाज के लिए बिल्कुल उपयुक्त नहीं था।

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

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

प्रारंभिक विमान के संरचनात्मक मुद्दों के बाद A380 और B787 दोनों को अपने पंख डिजाइन को संशोधित करना पड़ा।

सभी क्षेत्रों में मनुष्यों के लिए बड़ी जटिल परियोजनाएँ कठिन हैं।

Comments

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

— बेन ब्रोका

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

— यूफोरिक

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

— प्वाईंट

और यह देखते हुए कि A380 को 2010 के रूप में हाल ही में एक प्रमुख रिकॉल था, तब भी मैं इसे "निर्दोष" नहीं कहूंगा।

— मुहम्मद अल्करौरी

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

— सिल्वरबैकनेट

Answer 5

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

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

व्यक्तिगत अनुभव से दस परियोजनाओं में से केवल एक ही निर्मित होती है। यह प्रक्रिया डिजाइन-संचालित होने के बजाय विकास से प्रेरित है, इसलिए स्टील की कीमत जैसे ही कुछ बढ़ जाती है पूरी परियोजना खिड़की से बाहर है, या डिज़ाइन की गई है, क्योंकि डिज़ाइन प्रक्रिया का सबसे सस्ता घटक है।

योजनाबद्ध अवधारणा के लिए डिजाइन में एक महीने का समय लगता है, डिजाइन के विकास में दो से छह महीने, आर्किटेक्ट्स की एक टीम द्वारा विवरण और निर्माण दस्तावेजों के लिए एक और छह महीने, योजना सलाहकार, स्ट्रक्चरल इंजीनियर, विंड इंजीनियर, सर्विसेज इंजीनियर, मात्रा और लागत सलाहकार, सर्वेक्षक, पहुंच इंजीनियरों और सूची में चला जाता है ...

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

जटिलता-वार के अंतर हैं, लेकिन कुल मिलाकर यह शायद उसी के बारे में है। हमारे पास न केवल परस्पर संबंधित इकाइयाँ और कई स्तर के तीक्ष्ण सार और इंटरफेस हैं, बल्कि लोगों को प्रक्रिया के छोटे हिस्सों में बहुत अधिक विशेषज्ञता प्राप्त है जो संचार को बहुत मुश्किल बनाते हैं।

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

ओपी के प्रश्न के अनुसार कुल मिलाकर मेरा (संभावित रूप से गलत) अनुमान यह है कि इंजीनियरिंग की तुलना में प्रोग्रामिंग एक कला है। लोग आनंद क्यों लेंगे और यहां तक ​​कि इसे मुफ्त में भी करेंगे, इसमें अभिव्यक्ति और लालित्य पाएंगे। कंप्यूटर विज्ञान भी (टिन पर के रूप में) इंजीनियरिंग से अधिक एक विज्ञान है। आप मौजूदा कलपुर्जों को एक साथ पैच करने के बजाय एल्गोरिदम को साबित करने की कोशिश क्यों करेंगे और चीजों को सिर्फ काम करने के लिए काम करेंगे? यकीन नहीं अगर यह कोई मतलब है; मैं सॉफ्टवेयर आदमी नहीं हूं।

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

Comments

+1 अंतर्दृष्टि के लिए धन्यवाद। "डिजाइन करने के लिए यदि आप जानते हैं कि चीजें कैसे काम करती हैं" -> "डिजाइन करने के लिए यदि आप नहीं जानते कि चीजें कैसे काम करती हैं"?

— टोक़

हे बिल्डर, मैंने इस पोस्ट में कुछ संपादन सुझाए हैं, मुझे लगता है कि आपके पास उत्कृष्ट बिंदु हैं, मैंने सिर्फ कुछ व्याकरण को साफ करने की कोशिश की है।

— स्टीवन

मैं निश्चित रूप से इस बात से सहमत हूं कि प्रोग्रामिंग इंजीनियरिंग से अधिक एक कला है। मैं अक्सर सॉफ्टवेयर डिजाइन में एक मुख्य पहलू के रूप में रचनात्मकता पाता हूं।

— लैंजाफमे

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

— साइमन रॉब

कुछ लोग डिजाइन करते हैं और आनंद के लिए इमारतों का निर्माण करते हैं। अपने नियोक्ता को न बताएं, लेकिन अब जब मुझे लगता है कि यह मेरे कुछ सॉफ्टवेयर सागरदा फेमिलिया की तरह है : Idiosyncratic, बहुत सारे गहने, कभी खत्म नहीं हुए; लेकिन दिलचस्प डिजाइन, निर्माण और उपयोग करने के लिए मजेदार और अभी भी खड़ा है।

— पीटर ए। श्नाइडर

Answer 6

फिर उन लोगों के डिजाइन में कितना समय लगा? साल? दो? दस साल? डिजाइन किसी चीज के निर्माण का सबसे जटिल हिस्सा है, निर्माण स्वयं आसान है।

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

निर्माण खुद संकलक द्वारा स्वचालित रूप से नियंत्रित किया जाता है। और इसके लिए धन्यवाद, हम कुछ ही मिनटों में पूरे उत्पादों का निर्माण करने में सक्षम हैं।

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

Comments

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

— नाथन लॉन्ग

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

— TMN

"सॉफ्टवेयर डेवलपमेंट ज्यादातर डिज़ाइन प्रक्रिया है जहाँ डिज़ाइन दस्तावेज़ स्रोत कोड है" धन्यवाद।

— भाई केविन डी।

@ टीएमएन कल्पना कीजिए कि अगर गगनचुंबी इमारत बनाते समय, वे इंटीरियर के रंग पैलेट को बदल देंगे क्योंकि यह सही नहीं दिखता है। कि इमारत के किसी भी घटक के लिए आवेदन करें। एक ही शाफ्ट पर कई एलेवेटर चलाने की कोशिश करना एक बात है, लेकिन आपको शाफ्ट को उन सभी को हुक करने की कोशिश करने से पहले अलग-अलग सप्लायर से 20 एलेवेटर का परीक्षण करना होगा ...

— Lourec Faure-Lacroix

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

— TMN

Answer 7

कल्पना कीजिए, एयरबस ए 380 के डिजाइन के बीच में, किसी ने एक बैठक में पाइप किया और कहा, "हेह, क्या यह एक हवाई जहाज के रूप में बना सकता है?" अन्य लोगों ने कहा, "हाँ, हाँ। एक हवाई जहाज। अधिक पंख बेहतर हैं।" अगले कुछ वर्षों में A380 डिज़ाइन को एक त्रिभुज में बदलकर बिताया जाता है। एक और बैठक में, कोई कहता है, "एक त्रिभुज? यह पुराना है। हम एक द्विपदीय चाहते हैं। बस एक पंख को हटा दें।"

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

ये हैं, लेकिन कुछ कारण हैं कि सॉफ्टवेयर प्रोजेक्ट्स, बड़े और छोटे, एक खतरनाक दर से विफलता में समाप्त होते हैं।

Comments

ठीक ऐसा ही होता है। प्रबंधन प्रकार या क्लाइंट हर 10 सेकंड में अपना दिमाग बदलते हैं जो सिर्फ डेवलपर्स को निराश करता है। मैंने अपनी पिछली नौकरी इस तरह से बकवास की वजह से छोड़ दी

— एरिन ड्रमंड

यह समझ में आता है: youtube.com/watch?v=BKorP55Aqvg&feature=kp

— चमत्कारिक

Answer 8

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

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

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

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

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

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

Comments

+1। मानकीकरण के लिए अच्छा उदाहरण (एक साधारण बोल्ट की मानक शीट)। आईटी में, दुर्लभ ऐसे घटक हैं जो सामान्यीकृत होते हैं। पंजीकरण फॉर्म लें: प्रत्येक वेबसाइट अपने स्वयं को

— सुदृढ़

@ मेनमा: खराब उदाहरण, क्या आप अपने बटन, टेक्स्ट बॉक्स, विकल्प बॉक्स, डिव से ऑप्शन बॉक्स बनाते हैं? नहीं, आप ब्राउज़र के फार्म तत्वों का पुन: उपयोग करते हैं; और ब्राउज़रों ने ऑपरेटिंग सिस्टम के फॉर्म एलिमेंट्स का उपयोग किया।

— रेयान

मैं इंटर्नल के बारे में बोल रहा था, न कि नियंत्रणों के बारे में। कुछ रैंडम वेबसाइट लें। क्या आप पासवर्ड के लिए चीनी अक्षरों का उपयोग कर सकते हैं? क्या आप 25-वर्ण पासवर्ड का उपयोग कर सकते हैं? यदि आप पासवर्ड या उपयोगकर्ता नाम में व्हाट्सएप डालते हैं तो क्या होगा? यह सब सामान्यीकृत हो सकता है, लेकिन ऐसा नहीं है, और हर व्यक्ति हर परियोजना के लिए पहिया पुनर्रचना है, अक्सर बुरी तरह से, कोई हैशिंग और / या नमकीन, या पासवर्ड सोलह वर्ण (उदाहरण: एमएसएन) तक सीमित यानी, आदि

— Arseni Mourzenko

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

— mike30

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

— सेह

Answer 9

मुझे डर है कि मैं आपके बयान से असहमत हूं।

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

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

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

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

दूसरा बिंदु जो कई लोगों को याद आता है कि एक कार, एक टैंकर या एक विमान को बनाए रखने में कितना रखरखाव होता है जिसे हम जीवन के एक तथ्य के रूप में लेते हैं। हर विमान को टेक ऑफ करने से पहले तकनीकी जांच से गुजरना पड़ता है। आपको अपनी कार को हर कई k मील पर चेक-अप करना होगा और इतना नियमित सामान बदलना होगा जैसे तेल बदलना, टायर बदलना।

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

Comments

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

— केन ब्लूम

यह उच्च गुणवत्ता वाले सॉफ़्टवेयर का एक बेहतर उदाहरण है: 420,000 लाइनें और बग नि: शुल्क सॉफ्टवेयर: जिसने स्पेस शटल को संचालित किया । ध्यान रहे, इस तरह की गुणवत्ता प्राप्त करने से जुड़ी बहुत बड़ी लागतें थीं।

— dodgy_coder

@ डोडी_कोडर, एक सुरक्षित विमान बनाना या तो सस्ता नहीं है;;

— करीम आगा

@PaNNathan सभ्य बहुत व्यक्तिपरक है;)

— जेम्स

@ करीमा .: सुरक्षित विमान बनाना सस्ता नहीं है, लेकिन जो चीज किसी विमान को सुरक्षित बनाती है, वह सॉफ्टवेयर है ... इसलिए विमान डिजाइन का एक महत्वपूर्ण हिस्सा वास्तव में सॉफ्टवेयर डिजाइन है!

— विस्मय

Answer 10

डिजिटल बिल्डिंग ब्लॉक्स 1 या 0. हो सकता है, जिसमें कोई इनबिल्ट नहीं है।

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

कंप्यूटिंग की तार्किक और अंतरात्मक प्रकृति के कारण, कोई भी, यहां तक ​​कि बहुत छोटे बदलावों से भी भारी विफलता हो सकती है।

Comments

मैंने एक बार किसी को यह कहते हुए सुना कि "कंस्ट्रक्शन सिर्फ प्रोग्रामिंग की तरह होगा जब आप अंतिम डॉकर्नोब को घर के पीछे की तरफ लगाते हैं, तो पूरे घर में विस्फोट हो जाता है"।

— मॉर्गन हेरलॉकर

Answer 11

मैंने अक्सर एक ही बात को सोचा है। यह निश्चित रूप से लगता है (कभी-कभार) जैसे हम शौकीनों का एक झुंड है जो हमें पता नहीं है कि हम क्या कर रहे हैं। मैं उन स्पष्टीकरणों को नापसंद करता हूं जो दोष प्रबंधकों या अन्य बाहरी कारकों पर डालते हैं - हम जो बनाते हैं उसके लिए डेवलपर्स को जिम्मेदार होना चाहिए।

मुझे लगता है कि हम एक ऐसे व्यवसाय में हैं जहाँ त्रुटियाँ सस्ती हैं । एक गगनचुंबी इमारत के पुनर्निर्माण या हर बेचे गए सेलफोन को वापस लेने की तुलना में, पैचिंग सॉफ्टवेयर सस्ता है।

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

संक्षेप में मेरा मानना ​​है कि यह एक संस्कृति समस्या है, और मुझे आशा है कि यह बदल जाएगी।

Comments

क्या आप उन प्रोग्रामर्स को समझते हैं जो त्रुटि-मुक्त कोड का उत्पादन करने का हर संभव प्रयास नहीं करते हैं, क्योंकि कल तक

— बीटा

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

— मोम

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

— खौफ

Answer 12

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

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

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

Answer 13

मुझसे कुछ सामान:

1- मानक और भाग: वे विमान निर्माता हैं , डेवलपर्स नहीं। मुझे पूरा यकीन नहीं है, लेकिन मेरा अनुमान है कि बहुत सारे हिस्से आउटसोर्स किए गए हैं। वे अपने स्वयं के इलेक्ट्रॉनिक / उपकरणों का निर्माण नहीं करते हैं, उन्हें किसी कंपनी से सीटें मिलती हैं, इंजन शायद कहीं और विकसित होते हैं, आदि।

दूसरी ओर, सॉफ्टवेयर प्रोजेक्ट, लगभग हमेशा कुछ छोटे फ्रेमवर्क / हेल्पर्स के साथ स्क्रैच से शुरू होते हैं।

2- बाजार में आने का समय: विमानों के लिए समय कोई महत्वपूर्ण मुद्दा नहीं है। मैंने शर्त लगाई कि एयरबस के डिजाइन को पूरा होने से पहले ही अंतिम रूप दे दिया गया था, और उन्होंने उस समय में होने वाली किसी भी बड़ी सफलता की उपेक्षा करने का फैसला किया। (कार निर्माताओं के लिए भी, उदाहरण के लिए, जो अत्याधुनिक तकनीक वे इस समय विकसित करते हैं, वह 5-10 वर्षों में सड़कों पर आ जाएगी।)

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

3- रिलीज-चक्र और संस्करण। - एक विमान पूरी तरह से समाप्त होने की जरूरत है जब वह "जारी" हो। कोई स्थिर बीटा संस्करण नहीं हैं, रात के निर्माण या समान हैं। इसके अतिरिक्त, एक बार यह हो जाने के बाद, इसे केवल एक छोटे तरीके से संशोधित किया जा सकता है। आप मौजूदा बोइंग में 100 सीटों के साथ एक अतिरिक्त स्तर नहीं जोड़ सकते, यह संभव नहीं है।

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

Answer 14

मुझे लगता है कि उत्तर काफी सरल है:

1) भौतिक निर्माण और कार्यान्वयन लगभग तब तक रहा है जब तक लोगों के पास है - भौतिक परियोजनाओं को लागू करने के लिए हमारे तरीकों और तकनीकों को विकसित करने के लिए हमारे पास हजारों साल हैं। सॉफ्टवेयर 'निर्माण', जिसके लिए पूरी तरह से नए और अलग कौशल-सेट की आवश्यकता होती है, 50 साल से अधिक पुराना नहीं है - हमारे पास अभी तक पर्याप्त समय नहीं है।

2) आभासी निर्माण कठिन है - आपको अपने दिमाग में उन चीजों को देखना होगा, जिनकी कोई वास्तविक वास्तविकता नहीं है। इसके लिए आपको बहुत सी जानकारी का विश्लेषण और सार करने की आवश्यकता है, इससे पहले कि आप यह भी जान लें कि आपका उत्पाद कैसा दिखता है और इसे बनाने के लिए क्या कदम उठाने चाहिए। पुल या बिल्डिंग बनाते समय ऐसा नहीं है।

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

Answer 15

मैं जैक गन्सल के एम्बेडेड संग्रह से एक लेख की एक शब्दशः प्रतिलिपि का उपयोग करके उत्तर देने का प्रयास करूंगा। जबकि यह फर्मवेयर हर जगह कहता है, बस इसे मानसिक रूप से सॉफ्टवेयर द्वारा प्रतिस्थापित करें।

क्या तुलना?

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

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

लेकिन सॉफ्टवेयर इतना महंगा क्यों है? टॉम डेमार्को ने एक बार इन तीन शब्दों के साथ इस प्रश्न का उत्तर दिया: किस की तुलना में? वह अपेक्षाकृत उबाऊ व्यावसायिक मामलों पर चर्चा करने के लिए गया था, लेकिन यह जवाब मेरे दिमाग में वर्षों से गूंजता रहा है। क्या तुलना? सॉफ्टवेयर के साथ हम नियमित रूप से अभूतपूर्व जटिलता के उत्पाद व्यवहार बनाते हैं। ज़रूर, कोड महंगा है। लेकिन सभ्यता के इतिहास में कभी किसी ने इतना जटिल कुछ भी नहीं बनाया है।

निम्नलिखित बुलबुले के प्रकार पर विचार करें, विकिपीडिया से बेशर्मी से उठाया और सटीकता के लिए जाँच नहीं की:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

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

एक मैकेनिकल इंजीनियर यह दावा कर सकता है कि उसका पेशा कंप्यूटर से बहुत पहले सॉर्टर्स का निर्माण करता है। आईबीएम के 1949 के युग के मॉडल 82 कार्ड सॉर्टर ( http://www.columbia.edu/acis/history/sorter.html ) पर 650 कार्ड प्रति मिनट के थ्रूपुट के साथ विचार करें , बल्कि हमारे कोड स्निपेट से कम 4 हर्ट्ज पर भी प्रबंधित हो सकता है Z80। मॉडल 82, निश्चित रूप से, एक समय में एक कार्ड के केवल एक कॉलम को छाँटता था; एक डेक को पूरी तरह से सॉर्ट करने के लिए दर्जनों पास हो सकते हैं।

इस जानवर को डिजाइन करने और बनाने में कितना समय लगा? साल, कोई शक नहीं। और इसकी कार्यक्षमता हमारे कोड की तुलना में अधिक है जो बहुत तेज है और जो विशाल डेटासेट को संभाल सकता है। लेकिन वह 1949 था। FPGAs और VHDL या CPU के बिना इलेक्ट्रॉनिक कंपोनेंट्स से बबल सॉर्ट बनाने में कितना समय लगेगा?

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

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

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

यह सब कोड की 7 छोटी लाइनों को बदलने के लिए है। कुछ वास्तविक एम्बेडेड प्रोग्राम 10,000 से कम हैं; कई लाख से अधिक है। एक वास्तविक, सुपर-आकार के कंप्यूटर प्रोग्राम को बदलने के लिए कितना हार्डवेयर और कितना इंजीनियरिंग की आवश्यकता होगी?

एक स्प्रेडशीट की तरह एक वास्तविक कार्यक्रम पर विचार करें। प्रोसेसर के बिना एक बनाने में कितना सर्किटरी लगेगा? यह एक शहर का आकार हो सकता है।

ब्रह्मांड में सबसे महंगी चीज फर्मवेयर है, लेकिन केवल समस्याओं की अकल्पनीय जटिलता के कारण यह हल करती है। लेकिन यह किसी भी विकल्प की तुलना में काफी सस्ता है। इसलिए जब आपका बॉस चिढ़ता है कि सॉफ्टवेयर को इतना लंबा समय क्यों लगता है, तो आप जानते हैं कि क्या कहना है। क्या तुलना?

इसलिए वहाँ! सॉफ्टवेयर / फर्मवेयर में अद्वितीय जटिलता है।

Answer 16

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

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

Comments

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

— एंडी बर्न्स

Answer 17

सभी डेवलपर्स समान रूप से नहीं बनाए गए हैं। कुछ अच्छे हैं, अन्य अच्छे हैं, नहीं।

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

Answer 18

कैथेड्रल को बनाने में 100 साल तक लगते थे।

कुछ एयरबस हवाई जहाज को काम करने के लिए 1 मिलियन लाइनों की आवश्यकता होती है।

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

Comments

कोलोन कैथेड्रल 1248 में शुरू किया गया था, और 1880 में समाप्त हुआ। 632 साल।

— gnasher729

Answer 19

बड़े संगठनों में अक्सर बड़े प्रोजेक्ट होते हैं। यदि आपने कभी बड़े संगठन में काम नहीं किया है, तो एक चीज है जो प्रदर्शन और उत्पादकता को मारने की गारंटी देती है: नौकरशाही।

हैरानी की बात है, कई लोगों को पता नहीं है कि नौकरशाही क्या है (यह अक्सर राजनीति से उलझन में है), या भले ही / जब वे नौकरशाही समस्या है।

हमने हाल ही में स्मार्ट कार्ड प्रमाणीकरण को लागू करने के लिए एक परियोजना का समापन किया। यह मूल रूप से तीन महीने में अनुमानित किया गया था। इसमें 15 महीने लगे। देरी के लिए कोई लागत, बजट, गुंजाइश या तकनीकी कारण नहीं थे। यह दायरा वास्तव में काफी संकीर्ण था - केवल उन्नत विशेषाधिकारों (प्रशासक खातों) वाले खातों के लिए, लगभग 1,200 कुल खाते।

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

Answer 20

मेरे पास आपके लिए एक छोटा संस्करण है:

जो कुछ करना आसान है, या सुव्यवस्थित है, हम उसके बजाय इसे करने के लिए एक कार्यक्रम लिखते हैं।

और फिर इसके बजाय मेटा-प्रक्रिया से लड़ें।

यह इतना सच नहीं है, प्रति से, लेकिन हर दिन ब्लॉग लिखने के बजाय हजारों ब्लॉग स्थापित किए जाते हैं। प्रत्येक कार्यदिवस, हजारों एक्सेल मैक्रोज़ लिखे जाते हैं, बजाय इसके लिए विशेष रूप से डिज़ाइन किए गए डेटाबेस एप्लिकेशन लिखने के।

कई अन्य कारक हैं - उनमें से कुछ का उल्लेख यहां किया गया है - लेकिन मैं इस बिंदु को चर्चा में जोड़ना चाहता था।

Comments

मैं सहमत हूँ। बड़े कार्यक्रमों को निर्दोष रूप से और समय पर वितरित किया जा सकता है, क्योंकि उन्हें 3 दशकों में सौ बार किया गया है। उदाहरण के लिए, एक पाठ संपादक।

— दरोगाओं

इतना ही नहीं, लेकिन जिस तरह से हम बड़े कार्यक्रमों को त्रुटिपूर्ण तरीके से करते हैं, जो पहले किया जा चुका है, तो क्या हम पुराने कार्यक्रम को उसकी वेबसाइट से डाउनलोड कर एक प्रति बना सकते हैं। लेकिन किसी कारण से जो एक सफल बड़े सॉफ्टवेयर प्रोजेक्ट के रूप में नहीं गिना जाता है।

— bdsl

Answer 21

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

Comments

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

— वेक्टर

अगर ऐसा होता तो लागत बढ़ती और सुविधाओं में कमी आती।

— जिम जी।

@JimG। सवाल विश्वसनीयता के बारे में था, न फीचर का और न ही कीमत का। निश्चित रूप से अधिक विश्वसनीय उत्पाद बनाने के लिए आपके डिजाइन स्थान में और अधिक बाधाओं का सामना करना पड़ेगा और अन्य पहलुओं (सुविधा और लागत) को नुकसान हो सकता है।

— ग्रेगेक जूल

और बोइंग 737 की लागत $ 50-80 मिलियन है। आप एक बार मिलने वाले प्रत्येक भुगतान करते हैं - क्या आप हर बार कार्यालय खोलने के लिए भुगतान करते हैं? अगर मुझे हर बार भुगतान किया जाता है तो किसी ने मेरे सॉफ्टवेयर का इस्तेमाल किया है जो सीधे तौर पर विश्वसनीयता के लिए समर्पित है।

— फ्लेवर्सस्केप

@ जिम जी: मैं 5 भद्दे लोगों के बजाय किसी उत्पाद के 1 स्थिर संस्करण को पसंद करूंगा।

— जियोर्जियो

Answer 22

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

यह संभव है लेकिन मुश्किल है, दोनों व्यावहारिक रूप से और मानव प्रकृति की बात के रूप में, सॉफ्टवेयर परियोजनाओं में।

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

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

Answer 23

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

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

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

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

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

Comments

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

— जूलिया हेवर्ड

Answer 24

"बड़ी परियोजना" की परिभाषा तिरछी है।

एक बड़ी परियोजना, तकनीकी रूप से, समय पर वितरित की जा सकती है, और त्रुटिपूर्ण रूप से, यह ऐसा कुछ है जिसे कई वर्षों में कई बार बनाया गया है।

• एक पैक-मैन क्लोन।
• कैलकुलेटर
• एक पाठ संपादक

मुझे यकीन है कि आप सोच रहे हैं ... "लेकिन वे छोटी परियोजनाएं हैं! एक पाठ संपादक सरल है ।" मैं आपसे असहमत होऊंगा। कंप्यूटर अपमानजनक रूप से जटिल हैं। बस ऑपरेटिंग सिस्टम पर उपयोगकर्ताओं को स्थापित करना और स्थापित करना कई बार मुश्किल हो सकता है, और आपने ओएस भी नहीं लिखा , या हार्डवेयर का निर्माण नहीं किया।

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

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

Comments

ब्लैक होल संचालित वैक्यूम क्लीनर? कार्यात्मक सुरक्षा के बारे में क्या?

— पीटर मोर्टेंसन

कार्यात्मक सुरक्षा की कमी? यह एक विशेषता है! हम ब्लैक होल वैक्यूम क्लीनर से कुछ साफ करने का प्रयास करते समय अपरिवर्तनीय संरचनाओं के उपयोग की वकालत करते हैं।

— दरोगनस

Answer 25

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

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

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

Answer 26

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

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

यात्रा: http://www.globalprojectstrategy.com/lessons/case.php?id=23 और देखें कि एयरबस A380 कितना सफल रहा।

Answer 27

सॉफ्टवेयर इंजीनियर यहां, एक इंजीनियरिंग पृष्ठभूमि के साथ, और एक पत्नी जो निर्माण में काम करती है। हमने अपनी नौकरियों के अंतर पर लंबी चर्चा (और तर्क) की है।

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

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

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

इंजीनियरिंग में कई नए डिजाइन नहीं हैं; एक अत्यंत कुशल इंजीनियर वह है जो किसी मौजूदा डिज़ाइन को किसी नई चीज़ में हेरफेर कर सकता है या उस पर सुधार कर सकता है। लेकिन लगभग हर प्रोग्रामर से उम्मीद की जाती है कि वे डिज़ाइनों को संशोधित करें, उन्हें हैक करें या कुछ नया बनाएँ।

विधानसभा से C से C ++ से जावा, जावास्क्रिप्ट, C #, PHP, और इतने पर मानकों को पूरी तरह से बदल दिया है, वापस देखो । बहुत सारे कोड नहीं हैं जो 10 या 20 साल पहले से पुनर्नवीनीकरण किए जा सकते हैं। यह कहना बहुत अलग है ... मोटर वाहन या वैमानिकी उद्योग जब आप दशकों से डिजाइनों में सुधार कर सकते हैं।

परियोजना प्रबंधन सॉफ्टवेयर में बहुत मुश्किल है । समय का अनुमान सबसे अच्छा काम करने वाले लोगों द्वारा किया जाता है , लेकिन जब वे अनुमान लगाने में व्यस्त होते हैं , तो वे कोड नहीं लिख रहे होते हैं । यह लोगों को किसी भी परियोजना प्रबंधन से बचने का प्रयास करता है।

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

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

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

छोटे प्रोजेक्ट बेहतर हैं । मेरी पत्नी ने एक बार मुझे एक बड़ी कंपनी में नौकरी करने के लिए कहा था। यह एक तर्क में समाप्त हुआ कि बड़ी कंपनियां खराब कंपनियां हैं ... उसके लिए, एक बड़ी कंपनी के पास बहुत सारे संसाधन, अनुभव, कार्यात्मक परियोजना प्रबंधन और सही प्रक्रियाएं थीं। मेरे लिए, एक बड़ी कंपनी एक डायनासोर है, जहां आपका अधिकांश समय कोड को ठीक करने, उसका परीक्षण करने और प्रलेखन पर खर्च होता है।

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

Answer 28

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

इसका एक कारण यह है कि सॉफ्टवेयर विकास एक सकारात्मक प्रतिक्रिया चक्र है क्योंकि सॉफ्टवेयर (प्रोग्रामिंग लैंग्वेज, बिल्ड टूल्स, आईडीई) का उपयोग सॉफ्टवेयर बनाने के लिए किया जाता है। रे कुर्ज़वील के रिटर्न में तेजी लाने के नियम के लिए यह सबसे स्पष्ट उदाहरण है, जिसके परिणामस्वरूप तेजी से विकास हो रहा है। एक बार जब आप एक फ्रेमवर्क, प्रोग्रामिंग लैंग्वेज, कम्युनिकेशन प्रोटोकॉल में महारत हासिल कर लेते हैं, तो आगे बढ़ने का समय आ जाता है ।

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

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

Comments

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

— आर्सेनी मूरज़ेंको

@ArseniMourzenko खैर, जावा वेब क्लाइंट प्रोग्रामिंग के लिए गर्म था जब वह बाहर आया था और GUI भवन के लिए जब स्विंग बाहर आया था, लेकिन दोनों ही कुछ साल तक चले। हेक, 1990 के दशक से पहले कोई डब्ल्यूडब्ल्यूडब्ल्यू नहीं था। वेब प्रोग्रामिंग वह जगह है जहाँ हवाई जहाज 1910 में थे। लेकिन यह गति जारी है।

— पीटर ए। श्नाइडर

Answer 29

मेरे लिए मुख्य समस्या यह है कि सॉफ्टवेयर इंजीनियरिंग चेहरा मामलों, उपयोगकर्ता और क्रॉस प्लेटफार्मों का उपयोग करता है।

बक्सों का इस्तेमाल करें

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

उपयोगकर्ता

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

प्लेटफ़ॉर्म पार करें

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

Answer 30

अगर आपको लगता है कि अन्य उद्योग बिना किसी घटना के प्रोजेक्ट पूरा करते हैं, तो आपको 1977 में निर्मित सिटीग्रुप सेंटर बिल्डिंग के बारे में कहानी पढ़नी चाहिए। योजना और निर्माण के लगभग 7 साल बाद भी, इमारत एक गंभीर डिजाइन दोष के साथ पूरी हो गई थी, जो एक पतन का कारण बनी। तूफान की घटना हर 16 साल में होने की उम्मीद है।

दूसरे शब्दों में, हर साल सिटिकॉर्प सेंटर के लिए खड़ा था, लगभग 1-इन -16 मौका था कि यह गिर जाएगा।

मूल डिजाइनर मुद्दों से अनजान थे, लेकिन सौभाग्य से यह इमारत का अध्ययन करने वाले छात्र द्वारा पकड़ा गया था।

सबकुछ ठीक-ठाक लग रहा था, जब तक कि लेमेसियर ने यह नहीं बताया, उन्हें एक फोन आया। LeMessurier के अनुसार, 1978 में एक स्नातक वास्तुकला के छात्र ने LeMessurier के भवन के बारे में एक साहसिक दावे के साथ उनसे संपर्क किया: Citicorp केंद्र हवा में उड़ सकता है।

डिजाइन दोष की गोपनीयता बनाए रखने के लिए लोगों की कम से कम राशि को शामिल करते हुए रात के कवर में मरम्मत की गई थी।

इमारत के आसपास के 10-ब्लॉक त्रिज्या के लिए एक आपातकालीन निकासी योजना तैयार की गई थी।

वे रात भर वेल्डेड थे और दिन के समय बाहर निकल गए, जैसे ही इमारत के रहने वाले काम पर लौट आए।

यह कहानी तब तक एक रहस्य बनी रही जब तक कि लेखक जो मॉर्गेनस्टर्न ने इसे एक पार्टी में नहीं सुना, और लेमेसियर का साक्षात्कार लिया। मॉर्गनस्टर्न ने 1995 में द न्यू यॉर्कर में कहानी को तोड़ दिया।

जो सवाल उठाता है; सार्वजनिक स्वीकृति के बिना परियोजनाओं में कितने अन्य घातक डिजाइन दोषों को गुप्त रूप से मरम्मत या अनदेखा किया गया था।

• लगभग एक NYC गगनचुंबी इमारत के बाहर मिटाया गया डिजाइन दोष (slate.com)
• सिटीग्रुप सेंटर (wikipedia.com)