सॉफ्टवेयर उद्योग का विनियमन [बंद]


85

हर कुछ वर्षों में किसी को सॉफ्टवेयर उद्योग के लिए सख्त विनियमन का प्रस्ताव है।

इस IEEE लेख में इस विषय पर हाल ही में कुछ ध्यान दिया गया है।

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

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

वह उद्धरण जो मेरे लिए है:

परीक्षा में बुनियादी ज्ञान की परीक्षा होगी, न कि विषय की महारत हासिल करने की

क्योंकि बड़ी विफलताएँ (जैसे THERAC-25 ) जटिल, सूक्ष्म मुद्दे लगती हैं कि "बुनियादी ज्ञान" कभी भी रोकने के लिए पर्याप्त नहीं होगा।

किसी भी स्थानीय मुद्दों (जैसे शीर्षक के मौजूदा संरक्षण कुछ क्षेत्रों में अभियंताओं की उपेक्षा):

उद्देश्य कुलीन हैं - क्वैक्स / चार्लटैन 1 से बचें और उन भेदों को स्पष्ट करें जो उनके सॉफ़्टवेयर को खरीदते हैं। क्या सॉफ्टवेयर उद्योग का तंग विनियमन कभी भी मूल लक्ष्य को प्राप्त कर सकता है?

1 चिकित्सा पेशे के विनियमन के रूप में वास्तव में करने का इरादा था।


3
मुझे उम्मीद है कि थॉमस ओवेन्स ने इसका जवाब दिया क्योंकि मुझे पता है कि उनके पास इसका सही जवाब है।
मेपल_शाफ्ट

3
इस विषय पर लोगों को क्या कहना है, यह मैं सुनना चाहता हूं, यह स्टैक एक्सचेंज क्यू एंड ए प्रारूप के लिए एक अच्छा प्रश्न है।
PersonalNexus

12
सच कहूं, मैं एक संवैधानिक संशोधन के पक्ष में हूं, जो प्रौद्योगिकी और राज्य के अलगाव को जन्म देता है, यह देखते हुए कि प्रौद्योगिकी को विनियमित करते समय सरकार कितनी स्पष्ट लगती है (यह भी देखें SOPA)
JohnFx

3
जब यह हर दिन बदलता है तो किसी उद्योग को कैसे विनियमित किया जा सकता है?
जॉन रेन्नोर

4
इन "अच्छे पर्याप्त" स्थितियों का एक बहुत कुछ नहीं है जो बाद में बगों को अक्सर प्रबंधन / विपणन की गलती का कारण बनता है: "शिप शिप!"
Aren

जवाबों:


105

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

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

- मिच थॉर्नटन, IEEE लाइसेंस और पंजीकरण के उपाध्यक्ष

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

  • वकीलों
  • डॉक्टरों
  • लेखाकार
  • परमाणु इंजीनियर
  • नाइयों ( मजाक नहीं )

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

केवल जिनके कार्यक्रम "सार्वजनिक स्वास्थ्य या सुरक्षा, सुरक्षा, संपत्ति, या अर्थव्यवस्था को खतरे में डाल सकते हैं" उनका परीक्षण करना होगा।

यह एक अस्पष्ट बयान है और उदार व्याख्या और आवेदन के लिए खुला है। मैं यह तर्क दे सकता था कि Apple Inc. या Facebook अमेरिकी अर्थव्यवस्था के अभिन्न अंग हैं - क्या मुझे अब उनके लिए कोड लिखने के लिए सरकार से विशेष लाइसेंस की आवश्यकता है, क्योंकि अगर मैं अपनी अक्षमता के साथ साइट को नीचे लाता हूं तो मुझे अमेरिकी को नुकसान हो सकता है अर्थव्यवस्था? अपनी आखिरी नौकरी में मैंने गलती से एक क्रोन लिफ्ट को एक दोषपूर्ण क्रोन नौकरी के साथ बंद कर दिया - संभवतः खाद्य आपूर्ति को खतरे में डाल दिया।

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

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

और क्या होगा यदि आप इन सभी व्युत्पन्न विषयों के लिए परीक्षण करते हैं? एक पल के लिए मान लीजिए कि ई-कॉमर्स वेब साइट पर काम करने वाले प्रत्येक प्रोग्रामर को ई-कॉमर्स सक्षम प्रोग्रामर के रूप में प्रमाणित किया जाता है। इसलिए? इस अचानक मतलब यह है कि इन प्रोग्रामर और कंपनियों वास्तव में होगा करना आवश्यक सत्यापन और PCI अनुपालन करने के लिए का निर्माण? यहां तक ​​कि अगर वे करते हैं - ग्लिच अभी भी होगा।

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

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

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

यह कुछ ऐसा है जिसे आप विकास में शामिल कर सकते हैं, लेकिन आप कभी भी प्रमाणीकरण के साथ परीक्षण नहीं कर सकते

यहाँ है कि क्या होगा अगर यह "प्रमाणन" प्रभावी हो जाता है: घटनाओं की संख्या बिल्कुल वैसी ही रहेगी। क्यों? क्योंकि यह एबीएस या इंसुलिन पंप की वास्तविक समस्या को समाप्त करने के लिए कुछ भी नहीं करता है ।


33
+1 उत्कृष्ट उत्तर। मुझे विशेष रूप से पसंद है: "बुनियादी ज्ञान की कमी कभी समस्या नहीं है।"
जोनाथन हेंसन

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

3
हालांकि मुझे लगता है कि मुझे लगता है कि पूरे IEEE विचार के साथ शुरू करने के लिए बकवास है। समस्या को ठीक करने के लिए सभी सरकार को अपना काम करना है। किसी को भी किसी भी नुकसान के लिए जिम्मेदार सभी को पकड़ो। यह अकेले समस्या की देखभाल करेगा
जोनाथन हेंसन

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

3
@ जोंथनथनसन फिर, मैं एसक्यूएल इंजेक्शन के अधिकांश उदाहरणों पर विचार करता हूं - ठीक है - बुनियादी ज्ञान की कमी ... लेकिन कुल मिलाकर, अच्छी पोस्ट। +1।
जेफ फेरलैंड

72

कितना भाग्यशाली है कि कोई भी चिकित्सा विनियमन के लिए धन्यवाद नहीं मरता है, कोई भी वित्तीय विनियमन के लिए धोखाधड़ी से आहत नहीं होता है, किसी ने भी अपने घर को आवास विनियमन के लिए धन्यवाद नहीं दिया है, किसी को भी नाई के विनियमन के लिए एक बुरा बाल कटवाने के लिए धन्यवाद नहीं मिलता है, और कोई भी विमान दुर्घटनाग्रस्त नहीं होता है विमान विनियमन के लिए धन्यवाद।

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


10
+1 "सॉफ़्टवेयर इंजीनियरों को पहले से ही संबंधित सुरक्षा-महत्वपूर्ण उद्योगों के सदस्यों के रूप में अत्यधिक विनियमित किया जाता है, और उन उद्योगों के बाहर इसकी बहुत कम आवश्यकता है"
ट्रेवर बॉयड स्मिथ

3
मुझे इस उत्तर का निंदक लहजा पसंद नहीं है। क्या आप कह रहे हैं कि विनियमन की कोई आवश्यकता नहीं है, क्योंकि विनियमन कभी भी किसी समस्या का हल नहीं करता है?
फ्रेड फू

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

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

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

32

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

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

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

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

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

अपडेट करें

मैं इस बारे में कुछ पिछली रात बीयर या दस के ऊपर सोच रहा था।

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

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

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

इसके अलावा, मैं सभी को याद दिलाता हूं कि कंप्यूटर एक शौक़ीन और अकादमिक प्रयास के रूप में शुरू हुआ। 80 और 90 के दशक के शुरुआती दिनों के यूनिक्स युद्धों के अलावा हमारे पास मुफ्त ऑपरेटिंग सिस्टम, मुफ्त संकलक, मुफ्त कार्यक्रम और इतने पर ... यह जल्दी समाप्त हो जाएगा। रिचर्ड स्टेलमैन, लिनुस टॉर्वाल्ड्स और डेनिस रिक्टी को हमारे द्वारा वश में करने वाली दुनिया धीरे-धीरे अस्तित्व से दूर हो जाएगी।

संक्षेप में, क्या मैं "मैं आपको $ 25 प्रति घंटे के लिए एक वर्डप्रेस सीएमएस साइट" या "500 डॉलर के लिए किसी भी आईफोन ऐप" के साथ प्रतिस्पर्धा करने के लिए थक गया हूं? वास्तव में क्यों नहीं? क्योंकि मैं जो करता हूं, उस पर बहुत अच्छा लगता हूं और जो ग्राहक चाहते हैं, उत्कृष्टता के लिए देने को तैयार हैं। जब मैं स्वतंत्र रूप से या अपने रोजगार के स्थान पर परियोजना लेता हूं, तो मैं अपने f * & ^ के जोखिम को अपने सिर और प्रतिष्ठा पर लेता हूं। मैं जहां भी जाऊंगा मेरा पीछा करेगा। इसके अलावा, ज्यादातर लोग जानते हैं कि उन्हें वही मिलता है जो वे भुगतान करते हैं। एक ग्राहक जो केवल मुझे उस कीमत का भुगतान करने के लिए तैयार है जो वे अपने लॉन के आदमी को भुगतान करते हैं, वैसे भी किसी भी तरह से निपटने के लिए एक बुरा सपना होने जा रहा है। यदि सरकार ने सेवा प्रदाताओं को उनके नुकसान की भरपाई के लिए बाध्य करने के लिए कानूनी संरचना तय की, तो बहुत कम खराब प्रोग्रामर होंगे जो अभी भी क्षेत्र में रोजगार रखते थे।

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


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

4
@ जोनाथन हेंसन: वे निश्चित रूप से, सामान्य रूप से नहीं करते हैं। दुकानों के बहुत सारे जोएल टेस्ट में शून्य स्कोर करते हैं। ( joelonsoftware.com/articles/fog0000000043.html ) जैसा कि वे नहीं करना चाहिए , यह एक व्यापार निर्णय एक नैतिक निर्णय नहीं है। उन सभी चीजों में पैसा खर्च होता है: बहुत सारे और बहुत सारे पैसे। यदि आप एक विमान नियंत्रण प्रणाली का निर्माण कर रहे हैं, तो यह उन लागतों को लेने के लिए लंबे समय में लाभदायक है; अगर आप फेसबुक गेम बना रहे हैं, तो शायद नहीं।
एरिक लिपर्ट

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

1
@ और, मुझे लगता है कि हमें इस साइट का शीर्षक बदलने के लिए स्टैक एक्सचेंज से सॉफ्टवेयरेंग्रेनर्स.स्टैकएक्सचेंज डॉट कॉम पर पूछना चाहिए :)
जोनाथन हेंसन

1
@ जोनाथनहैसन ऑफ़ेंड? कोई रास्ता नहीं, चिंता मत करो! :) मुझे इसे थोड़ा और स्पष्ट करना चाहिए था कि मैंने लिंक को सिर्फ इसलिए पोस्ट किया क्योंकि यह आपकी टिप्पणी के लिए अजीब संयोग था।
यानिस

23

सिलिकॉन वैली समाचार - 31 जून, 2015

डरावनी: अप्रमाणित प्रोग्रामर ने कार्यक्रम को निरस्त कर दिया

"मैं फिर कभी नहीं चल पाऊंगा", पीड़ित को आउटपुट देता है। पुलिस जांच कर रही है।

आपराधिक: डॉ। एच। ए .के। जूनियर का लाइसेंस सूचक के गलत उपयोग के लिए निरस्त कर दिया गया और सिस्टम फ़ाइल से पढ़ने का प्रयास किया गया

एडवोकेट का कहना है कि सुप्रीम कोर्ट में अपील होने वाली है।

घोषणाएँ: 1975 में प्रमाणित कोबोल प्रोग्रामर को 2025 के बाद कोई पुनरावृत्ति नहीं करनी चाहिए

IEEE की पुष्टि के बाद से प्रमाणीकरण नहीं बदला।

विज्ञापन: मैजिक नॉलेज स्टफ़र्स, इंक के साथ प्रमाणन की गारंटी

21 दिनों में खुद को प्रोग्रामिंग सिखाएं।


मैं यह तय करने की कोशिश कर रहा हूं कि क्या यह एक संपूर्ण जवाब है या एक विनम्र टिप्पणी है। (दोनों शायद?)
लिंडन व्हाइट

@Oxinabox जून 31 तारीख विनोदी है
कुटकी

"अपने आप को 10 दिनों में प्रोग्रामिंग सिखाओ!" hehe
B 6овић

20

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

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

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

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

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

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

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

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

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

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


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

"तीन में से दो एक कुशल इंजीनियर का ध्यान आकर्षित करते हैं" आप सही कह रहे हैं, अंतरिक्ष शिल्प सभी मुश्किल नहीं है
zzzzBov

मामले पर अपना इनपुट जोड़ने के लिए +1 धन्यवाद। मुझे आशा है कि आप बेहतर महसूस करेंगे।
जोनाथन हेंसन

12

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

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

लोग गलती करते हैं, और विनियमन की कोई भी राशि आपदाओं को होने से नहीं रोकेगी। नासा पर विचार करें, जो अब तक आदमी को ज्ञात सॉफ्टवेयर विकास के लिए सबसे कठोर आवश्यकताओं से है। क्या उनके पास अभी भी सॉफ़्टवेयर बग्स हैं? (हाँ, हाँ, और कई बार, हाँ!)

बाज़ार नियमों की तुलना में इन समस्याओं को बहुत बेहतर तरीके से सुलझाता है। सॉफ़्टवेयर जो समस्याएं पैदा करते हैं, वे उन लोगों को जिम्मेदार ठहराते हैं जो घायल हुए हैं। हममें से बाकी लोगों को उनकी गलतियों के लिए भुगतान करने की आवश्यकता नहीं है।


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

1
@maple_shaft, सॉफ्टवेयर इंजीनियरिंग के लिए डॉक्टरों / वकीलों की तुलना करना IMO मान्य नहीं है। तुलना करने के लिए फ़ील्ड बहुत अलग हैं (यह देखने के लिए कि जारोद नेट्टल्स का उत्तर यह देखने के लिए क्यों आप सॉफ़्टवेयर इंजीनियरिंग की तुलना डॉक्टरों / वकीलों से नहीं कर सकते हैं)।
ट्रेवर बोयड स्मिथ

1
@maple_shaft - आप अनुमान लगा रहे हैं कि प्रमाणीकरण से इंजीनियरिंग की गुणवत्ता में सुधार होगा। मुझे काफी संदेह है कि इसका परिणाम क्या होगा। मुझे लगता है कि अधिकांश परीक्षणों के लिए अध्ययन में लगने वाला समय बेहतर इंजीनियरिंग सीखने में खर्च नहीं होता है।
Psr

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

1
@maple_shaft जो पूरी तरह से विफलता की प्रकृति पर निर्भर करता है - फेसबुक जवाब नहीं दे रहा है महत्वपूर्ण नहीं है (निवेशकों की जेब को प्रभावित करने से परे) - फेसबुक आपके सभी व्यक्तिगत विवरण और निजी संदेश हर इंटरनेट उपयोगकर्ता के लिए उपलब्ध कराना अलग बात है। इसके अलावा - ऐसे ऐप्स / गेम जो क्रेडिट कार्ड की जानकारी लेते हैं (जैसे फेसबुक पर) गलती से क्रेडिट कार्ड विवरण जारी करने से गंभीर नतीजे होंगे।
होरस्कॉल

11

1999 में, ACM ने लाइसेंस देने पर एक बयान जारी किया जब यह काफी हद तक IEEE SWEBOK के काम से बाहर हो गया। सार्वजनिक रूप से उपलब्ध SWEBOK दस्तावेजों और ACM स्टेटमेंट की समीक्षा करने के बाद, मैं ACM की राय का समर्थन करता हूं।

लेख को देखते हुए, परीक्षा लेने के लिए 4-6 वर्षों के अनुभव वाले व्यक्ति की आवश्यकता होती है, जो बुनियादी ज्ञान के लिए परीक्षा देता है। यह हास्यास्पद से परे है, और दरवाजे से बाहर हँसना चाहिए।


10

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

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

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

इसका वास्तव में "प्रोग्रामिंग" और "इंजीनियरिंग" के साथ सब कुछ करने के लिए कुछ भी नहीं है।

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


5
+1 IMHO, जो आप वास्तव में इशारा कर रहे हैं, वह यह है कि विनियमन उत्पाद पर होना चाहिए, इंजीनियरों को नहीं। उदाहरण के लिए, आग और घुसपैठ अलार्म सिस्टम के लिए आवश्यक विनियम (अनुमोदन) सॉफ्टवेयर कार्यों को सुनिश्चित करते हैं, न कि इंजीनियरों की क्षमता जिन्होंने इसे लिखा है। (कई नियम बहुत हद तक समान हैं जब सिस्टम पूरी तरह से इलेक्ट्रॉनिक सर्किट से बनाए गए थे।)
jernerny

8

विमान उद्योग में सॉफ्टवेयर को पहले से ही कसकर नियंत्रित किया जाता है। DO-178B देखें ।

मुझे यकीन है कि उद्योग के अन्य सबसेट के पास अपने मानदंड हैं।

"सॉफ्टवेयर" इन दिनों बहुत शामिल है। मुझे लगता है कि किसी भी अनिवार्य सभी तरह के विनियमन को छोड़ना बेतुका होगा।


4

सॉफ्टवेयर उद्योग का विनियमन गुणवत्ता आश्वासन प्रक्रियाओं के विनियमन के माध्यम से सबसे अच्छा किया जाता है।

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

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


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

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

3

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

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

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

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


1
+1 - के लिए: "अधिकांश सुरक्षा महत्वपूर्ण त्रुटियाँ एकीकरण त्रुटियाँ हैं।" वास्तव में, हम जिस प्रक्रिया से गुजरते हैं, उसमें लगभग कभी भी कोई कोडिंग त्रुटि नहीं होती है। 99.98% समय यह विभिन्न मॉड्यूल और उपकरणों के बीच एक समझ की समस्या है कि उन्हें कैसे काम करना चाहिए था।
डंक

@ डंक धन्यवाद, यह वास्तव में लेविसन से एक कौए है। एक तथ्य जो मुझे पाठ में शामिल करने के लिए था, लेकिन ऐसा लगता है कि मैं भूल गया :)
रून FS

2

कोई भी चार्लता और खदानों को पूरी तरह से समाप्त नहीं कर सकता है क्योंकि वे लंबे समय से स्थापित प्रथाओं और परंपराओं के बावजूद लगभग हर पेशे, यहां तक ​​कि चिकित्सा व्यवसायों में मौजूद हैं।

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

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

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


4
आमतौर पर इस तरह के नियमों को कानूनी आवश्यकताओं के रूप में अच्छी तरह से हवा दी जाती है। उदाहरण के लिए, सिविल इंजीनियरिंग
पॉल नाथन

@PaNNathan अच्छा बिंदु, यही वजह है कि एक सार्वभौमिक रूप से स्वीकृत अनुशासन के लिए प्राकृतिक प्रगति आत्म नियमन (उदाहरण के लिए। MPAA) पर शुरू होती है और अंततः कानून द्वारा विनियमन (राज्य बोर्डों, FCC, आदि ...)
Maple_shaft

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

1
सॉफ्टवेयर इंजीनियरिंग के लिए मैकेनिकल इंजीनियरिंग की तुलना करना मुझे आश्चर्यचकित करता है कि वास्तविक दुनिया इंजीनियरिंग एनालॉग आधुनिक ऑपरेटिंग सिस्टम की तरह क्या होगा।
FrustratedWithFormsDesigner

1
@maple_shaft - मूल समस्या यह है कि आप लिनक्स / बीएसडी / grep / vi / Firefox आदि का उपयोग नहीं कर सकते क्योंकि वे एक आधिकारिक एसई द्वारा लिखित नहीं हैं। जबकि VB में MSCE सर्टिफिकेट वाला कोई व्यक्ति ठीक होगा।
मार्टिन बेकेट

1

मैं इसे तंग नियमन नहीं कहूंगा, लेकिन इसके बजाय प्रवेश के लिए बाधाएं हैं। उस संबंध में मुझे लगता है कि योग्यता है। बढ़ी हुई गुणवत्ता के लिए, यह बहुत ही बहस का विषय है।

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

जब हम सामूहिक रूप से पूरे निर्णय लेते हैं कि शायद प्रवेश के लिए बाधाओं को बढ़ाने के लिए इसका समय है, उद्योग को उच्च स्तर पर रखने के लिए, हैकर / शिल्पकार से इंजीनियर तक विकसित होने के लिए, उस तरह का विनियमन मैं सभी पर कर रहा हूं।

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

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

कौशल का प्रदर्शन केवल एक परीक्षा लेने या "सम्मान का बिल्ला" प्राप्त करने से अधिक है। एक परीक्षण सिर्फ एक मान्यता है। वास्तविक मान्यता स्कूल है, इंटर्नशिप, प्रशिक्षुता, वरिष्ठों के तहत सलाह देना, अभ्यास करना, यह सब इसका एक हिस्सा है।

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


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

हायरिंग प्रक्रिया के दौरान कौशल का आकलन नहीं किया जाना चाहिए। ओह रुको, एचआर लोगों को कागजी क्रेडेंशियल (जो सॉफ्टवेयर विकास में लागू ज्ञान का प्रदर्शन नहीं करता है) के आधार पर काम पर रखता है और एचआर लोग सॉफ्टवेयर विकसित करने की जरूरतों / आवश्यकताओं के बारे में बिल्कुल कुछ नहीं जानते हैं। डबल फेल ...
इवान प्लाइस

0

मैंने लेख नहीं पढ़ा है, लेकिन अगर सवाल यह है कि क्या सॉफ्टवेयर उद्योग विनियमन मानवता को लाभ पहुंचा सकता है, तो मुझे लगता है कि यह परिस्थिति पर निर्भर करता है:

  1. पूरे उद्योग में कई प्रकार के डोमेन शामिल हैं, जिनमें से कुछ जीवन के लिए महत्वपूर्ण हैं (उदाहरण के लिए एक चिकित्सा उपकरण में विकिरण खुराक को नियंत्रित करना), और जिनमें से कुछ नहीं हैं ("कौन सा म्यूपेट आप हैं?" फेसबुक ऐप)। मैं उन अनुप्रयोगों के लिए नियमन के लिए कोई तर्क नहीं देख सकता जहाँ स्टेक कम हैं।

  2. किसी को कानूनी विनियमन से शुरू नहीं करना चाहिए । बल्कि, एक डेवलपर्स के लिए प्रमाणन कार्यक्रम के साथ शुरू होना चाहिए। केवल अगर प्रमाणन कार्यक्रम कुछ औसत दर्जे का लाभ पैदा करता है तो कानूनी विनियमन का प्रश्न होना चाहिए।

  3. यहां तक ​​कि अगर कोई प्रमाणन कार्यक्रम औसत दर्जे का परिणाम देता है, तो यह संभावना है कि उद्योग कड़ाई से व्यावसायिक कारणों के लिए इस प्रमाणीकरण की आवश्यकता पर मानकीकृत करेगा, और हमें कानूनी विनियमन की आवश्यकता नहीं होगी। (यही कारण है कि MCSE जैसे प्रतिनिधिमंडल मौजूद हैं - कंपनियां उन डोमेन के लिए MCSE को किराए पर लेना पसंद करती हैं जिनमें MCSE प्रशिक्षित हैं।)

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

IMHO।


0

मुझे इसका जवाब देना होगा ...

@JonathanHenson ने जो कहा उससे शुरू करके और @gnat की प्रविष्टि, जो मैं कहता हूं वह ठीक है, जिन लोगों के पास पैसा है वे प्रमाणित सामान के लिए भुगतान कर सकते हैं, जिन लोगों या देशों के पास पैसा नहीं है वे लाइसेंस के लिए भुगतान नहीं कर सकते हैं (प्रमाणित सामान के लिए बहुत कुछ ), तो वहाँ अभी भी renegades होगा अगर वह व्यवहार में हो जाता है। भले ही पारंपरिक (और इतना पारंपरिक नहीं) पहुंचाने के तरीके बंद हैं, फिर भी लोग इच्छुक उपयोगकर्ताओं को सॉफ़्टवेयर वितरित करने के तरीके खोज लेंगे। यहां तक ​​कि अगर इसका मतलब है कि एक और HTTP प्रोटोकॉल या यहां तक ​​कि एक वैकल्पिक पूरे नेटवर्क स्टैक को विकसित करना है, तो केवल कनेक्शन को अवांछनीय बनाने में ध्यान केंद्रित करें (किसी व्यक्ति के लिए अंतिम पैराग्राफ देखें, जो ऐसा करने में सक्षम हो सकता है)।

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

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

आखिरकार, आप हैकिंग ग्रुप्स (ब्लैक हैट हैकर ग्रुप्स नहीं, बल्कि व्हाइट या ग्रे हैट ग्रुप्स) के बारे में क्या कहते हैं, जो कि सिक्योरिटी के बारे में ज्यादा जानते हैं और सिक्योरिटी सॉफ्टवेयर को इस तरह से विकसित करते हैं, जो केवल कुछ सरकारी विभागों के सबसे खास प्रोग्रामर से मेल खाते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.