क्या सॉफ्टवेयर विकास एक इंजीनियरिंग अनुशासन है?


16

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

कार्नेगी मेलन विश्वविद्यालय में सॉफ्टवेयर इंजीनियरिंग संस्थान है जो CMMI मानकों को निर्धारित करता है और उनका रखरखाव करता है। क्या यह कुछ ऐसा है जो विकास को इंजीनियरिंग में बदल देगा?


जवाबों:


20

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

हाँ, सॉफ्टवेयर इंजीनियरिंग एक इंजीनियरिंग अनुशासन है।

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

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

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

ग्लेन वेंडरबर्ग के पास "रियल सॉफ्टवेयर इंजीनियरिंग" नामक वार्ता की एक श्रृंखला है, जो 2010 और 2015 के बीच कई सम्मेलनों में दो संबंधित वार्ता, "क्राफ्ट, इंजीनियरिंग और प्रोग्रामिंग के सार" के साथ दिया गया है (2011 में एक के रूप में दिया गया) RailsConf में मुख्य) और "क्राफ्ट एंड सॉफ्टवेयर इंजीनियरिंग" (2011 में QCon लंदन में दिया गया)। मुझे लगता है कि ये वार्ता एक बहुत व्यापक तर्क है कि सॉफ्टवेयर इंजीनियरिंग एक इंजीनियरिंग अनुशासन क्यों है।

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

क्या वह [CMMI] कुछ है जो विकास को इंजीनियरिंग में बदल देगा?

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

इसके अलावा, सॉफ्टवेयर इंजीनियरिंग पाठ्यक्रम / प्रमाण पत्र पर आपकी क्या राय है?

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


9

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

चाहे आप दोनों के लिए एक विमान या एक सॉफ्टवेयर एप्लीकेशन डिजाइन करें:

  • डिजाइन बनाते हैं
  • उप-प्रणालियों और घटकों को परिभाषित करें
  • प्रोटोटाइप बनाएं
  • परीक्षण निर्दिष्ट करें और निष्पादित करें
  • आदि।

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

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

यही कारण है कि मैं विकासशील सॉफ्टवेयर को इंजीनियरिंग मानता हूं।


2
अपने अनुभव को साझा करने के लिए धन्यवाद, कई "डेवलपर्स" को कोई अवधारणा नहीं है कि इंजीनियरिंग वास्तव में क्या है। चीयर्स!
लेउडी

7

मैं तर्क दूंगा कि सॉफ्टवेयर इंजीनियरिंग जैसी कोई चीज नहीं है।

इंजीनियरिंग में समस्याओं के समाधान के लिए वैज्ञानिक ज्ञान का व्यवस्थित अनुप्रयोग शामिल है। आज जो समस्याएँ हैं उनसे निपटने की जटिलता यह नहीं है कि निर्माण प्रक्रिया या उपकरण के निर्माण में एक मैकेनिकल इंजीनियर को तैयार करने में एक सर्किट या एक केमिकल इंजीनियर बनाने में एक इलेक्ट्रिक इंजीनियर से निपटने वाले लोगों से अलग हैं।

तथ्य यह है कि मौजूदा योजनाओं (इस मामले में विकास) को लागू करने का एक हाथ-पर-दृष्टिकोण भी केवल इस तथ्य के समान है कि अन्य क्षेत्रों में कोई और उन योजनाओं को क्रियान्वित करता है (उदाहरण के लिए, निर्माण कार्यकर्ता)।

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

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

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


5

नहीं, यह इंजीनियरिंग नहीं है। हम उस वैज्ञानिक नहीं हैं और हमें उन राज्य इंजीनियरिंग परीक्षणों में से कोई भी पास नहीं करना है। वास्तव में, परीक्षण के अभाव में कुछ जगहों पर खुद को सॉफ्टवेयर "इंजीनियर" कहना गैरकानूनी है।


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

कृपया प्रमाण दें।
थॉमस ओवेन्स

1
यहाँ यह ऑर्ड्रे डेस इन्ग्निएयर्स एफएक्यू से है। oiq.qc.ca/cgi-bin/…
केना

2
निर्भर करता है कि आप क्या कर रहे हैं। सॉफ्टवेयर इंजीनियरिंग डिग्रियां हैं जो P. Eng पदनाम के लिए योग्य हैं। यदि आप परमाणु संयंत्रों को नियंत्रित करने या किसी को मंगल पर भेजने के लिए सॉफ़्टवेयर का निर्माण कर रहे हैं, तो आप वास्तव में एक इंजीनियर होने की आवश्यकता है।
१lo:०६

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

5

IMHO शब्द 'सॉफ्टवेयर इंजीनियरिंग' को केवल प्रोग्रामर होने के बजाय एक डेवलपर द्वारा की जाने वाली चीजों की श्रेणी का बेहतर वर्णन करने की कोशिश करने के लिए तैयार किया गया था (जिसमें थोड़ा विचार या रचनात्मकता के साथ कुछ यंत्रवत प्रक्रिया से आगे निकल गया है)।

व्यक्तिगत रूप से मैं एक डेवलपर की उभरती सादृश्यता को 'शिल्पकार' के रूप में पसंद करता हूं, जो व्यावहारिक प्रोग्रामर द्वारा, दूसरों के बीच में चैंपियन है।

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


लेकिन विनिर्माण इंजीनियरिंग का केवल एक क्षेत्र है। तर्क है कि सॉफ्टवेयर विकास! = विनिर्माण दिलचस्प है, लेकिन सीधे एक तर्क के लिए प्रासंगिक नहीं है कि सॉफ्टवेयर विकास इंजीनियरिंग का हिस्सा है या नहीं। विमान का डिज़ाइन बिलकुल भी विनिर्माण जैसा नहीं है, लेकिन दोनों इंजीनियरिंग के क्षेत्र हैं।
MarkJ

5

विकी से:

अभियांत्रिकी :

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

सॉफ्टवेयर विकास

सॉफ्टवेयर विकास गतिविधियों का वह समूह है, जिसके परिणामस्वरूप सॉफ्टवेयर उत्पादों का निर्माण होता है। सॉफ्टवेयर विकास में अनुसंधान, नया विकास, संशोधन, पुन: उपयोग, पुन: इंजीनियरिंग, रखरखाव या सॉफ़्टवेयर उत्पादों में परिणामी अन्य गतिविधियाँ शामिल हो सकती हैं। [१]

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

तो वे बहुत समान हैं और एक ही चीज का मतलब भी कर सकते हैं।


1
मेरे फ़ंक्शन का नाम वास्तव में "सॉफ़्टवेयर डेवलपमेंट इंजीनियर" है ... वास्तव में अब उलझन में है: s
fretje

4

Dictionary.com से: en · gi · neer · ing / ʒəˈndɪənɪŋr · /

-नौ 1. 1. इंजन, पुल, भवन, खदान, जहाज और रासायनिक संयंत्रों के निर्माण में, भौतिक विज्ञान या रसायन विज्ञान के रूप में, शुद्ध विज्ञान के ज्ञान का व्यावहारिक अनुप्रयोग करने की कला या विज्ञान।

मैं कहूंगा कि सॉफ़्टवेयर बनाना गणित और कंप्यूटर विज्ञान का व्यावहारिक अनुप्रयोग है, और संभवतः अनुप्रयोग के आधार पर किसी भी अन्य शुद्ध विज्ञान की संख्या है।

[संपादित करें] एफडब्ल्यूआईडब्ल्यू, मैं खुद को सॉफ्टवेयर इंजीनियर नहीं कहता, लेकिन एक सॉफ्टवेयर डेवलपर इसलिए मुझे इसमें कोई व्यक्तिगत हिस्सेदारी नहीं है।


3

मेरे विचार में एक सॉफ्टवेयर इंजीनियर और सॉफ्टवेयर डेवलपर दो अलग-अलग चीजें हैं।

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

एक सॉफ्टवेयर डेवलपर एक प्रोग्रामर से अधिक निकटता से संबंधित होगा, लेकिन डेटाबेस प्रबंधन आदि जैसे अन्य क्षेत्रों में अधिक कौशल के साथ।

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


मेरा मानना ​​है कि सॉफ्टवेयर डेवलपमेंट सॉफ्टवेयर इंजीनियरिंग की श्रेणियों में से एक है।
लेउडी

1

मैं यहाँ "नहीं" के साथ जा रहा हूँ। मेरा भाई एक मैकेनिकल इंजीनियर है, और उसने इंजीनियरिंग को "द आर्ट ऑफ बीइंग सस्ते" के रूप में वर्णित किया है:

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

प्रतिक्रिया में, मैं सॉफ्टवेयर विकास का वर्णन करने आया हूं (सॉफ्टवेयर इंजीनियरिंग नहीं - वे वास्तव में मौलिक रूप से दो अलग-अलग क्षेत्र हैं) "द आर्ट ऑफ बीइंग एफीशिएंट":

"डेवलपर्स अधिक चिंतित हैं जितना संभव हो उतना तेज़ी से किया जा रहा है, कम से कम लागत पर पुनरावृत्ति संभव है। "

अंतर उन वाक्यों के अंतिम भाग में है।


"इंजीनियरिंग" की अवधारणा पर अच्छा दृश्य, मजेदार और सच्चा।

मैं उसे बता दूंगा कि कोई और उससे सहमत है - उसे प्रसन्न होना चाहिए। : डी

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

मेरे लिए बहुत भयानक राय की तरह लगता है। क्या आप तथ्य के साथ बैकअप ले सकते हैं?
जेरेमी

रुको ... मैं उलझन में हूँ। किसकी राय से कैसा लगता है? मेरा या मेरे भाई का?

1

सॉफ्टवेयर डेवलपमेंट इंजीनियरिंग है?

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


2
मैं 35W पुल से कुछ मील की दूरी पर रहता हूं जो लगभग डेढ़ साल पहले भयावह रूप से विफल हो गया था। एक इंजीनियर होने का मतलब यह नहीं है कि आप पंगा लेने के लिए प्रतिरक्षा हैं।
डेविड थॉर्नले

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

शायद अंतर यह है कि जोखिम भरा कोड का परीक्षण करना आसान है?
kleineg

1

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

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

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

मैं एक निर्माण कार्यकर्ता और एक संरचनात्मक इंजीनियर के बीच अंतर को एक प्रोग्रामर और एक सॉफ्टवेयर इंजीनियर के बीच का अंतर बताता हूं।

स्पष्ट करने के लिए, मेरे पास केवल एक कॉलेज डिप्लोमा है, इसलिए मैं खुद को इंजीनियर नहीं कह सकता।


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

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

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

1

मैं 2 मुख्य कारणों से "इंजीनियरिंग" शब्द को सॉफ्टवेयर विकास का वर्णन करने के लिए सबसे उपयुक्त नहीं मानूंगा:

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

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

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


0

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

यह भी दोहराव है। आवश्यकताओं का एक सेट लें और इसे दो टीमों को दें। जब आप एक ही बात बाहर कर सकते हैं (टीमों के बिना एक दूसरे से बात कर रहे हैं) तो आप इंजीनियरिंग के बहुत करीब हैं।

इंजीनियरिंग के अन्य क्षेत्रों में भी दंड और कठोर समीक्षा और हस्ताक्षर बंद हैं। जवाबदेही।


0

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

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

इससे, मैं कटौती कर सकता हूं:

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

फिर, मुझे यह सुनिश्चित करने के लिए कि मुझे अपनी गणना सही ढंग से करनी है, मुझे डिज़ाइन को किसी तीसरे पक्ष (दूसरी कंपनी) से अनुमोदित और जाँच करवाना चाहिए।

फिर, जब पुल का निर्माण वास्तव में किया जाता है, तो यह काम एक मानक तरीके से योग्य लोगों द्वारा किया जाएगा। वे ऐसे काम कर रहे होंगे जो उन्होंने पहले कभी सैकड़ों, शायद हजारों बार किए होंगे।

मुझे गलत मत समझो, हर सिविल इंजीनियरिंग परियोजना अलग है, लेकिन ऐसा लगता है कि हर बार जब मैं एक नया एप्लिकेशन / वेबसाइट विकसित करता हूं, तो चीजें अलग-अलग हो जाती हैं।


0

हाँ मुझे लगता है कि विकास इंजीनियरिंग का सबसेट है:

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

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

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


0

सॉफ्टवेयर डेवलपमेंट इंजीनियरिंग है।

सॉफ्टवेयर इंजीनियरिंग के मानक को पूरा नहीं करने के लिए दूसरों द्वारा किए गए कुछ तर्क:

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

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

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

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