"सॉफ्टवेयर अभियान्त्रिकी": अवतरणों में अंतर

Content deleted Content added

Inline

18:20, 21 जून 2017 का अवतरण

यह सुझाव दिया जाता है कि इस लेख या भाग का सॉफ्टवेयर अभियान्त्रिकी के साथ विलय कर दिया जाए। (वार्ता)

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

इतिहास

यद्यपि "तन्त्रांश अभियान्त्रिकी" शब्द १९६८ में एक सम्मलेन में प्रयोग में लाया गया था, लेकिन जिन समस्याओं को ये संबोधित करता है वो बहुत पहले की है। तन्त्रांश अभियान्त्रिकी का इतिहास जटिल रूप से संगणक हार्डवेयर और संगणक तन्त्रांश के इतिहासों से गुथा हुआ है। सन् १९४१ में जब प्रथम डिजीटल संगणक अस्तित्व में आया, तब उसे चलाने वाले अनुदेश एक यन्त्र में होते थे जो तारो द्बारा संगणक से जुड़ा होता था। लेकिन शीघ्र ही व्यवसायियो ने ये अनुभव किया की ये ख़ाका अधिक लचीला नहीं है और तब "संग्रहित निर्देश संरचना" या वॉन निउमन स्थापत्य का विकास हुआ। १९५० से प्रोग्रामिंग भाषाएँ विकसित होने लगीं और ये भी मतिहीनता की और एक महत्वपूर्ण बढ़त थी। फौरट्रैन, अलगोल और कोबोल जैसी प्रमुख भाषाएँ १९५० के अंतिम वर्षों में आई जो वैज्ञानिक, प्रतीकगणितीय और व्यावसायिक समस्याओं को सुलझाने के लिया बनी थी।

softwere are good fo cumputers

बाहरी कड़ियाँ

Guide to the Software Engineering Body of Knowledge
Computer Software Engineers - Definition and statistics from the U.S. Bureau of Labor Statistics
IEEE Software Engineering Online
A Student's Guide to Software Engineering Projects - a free online guide for students taking SE project courses

@@ पंक्ति 6: / पंक्ति 6: @@
 यद्यपि "तन्त्रांश अभियान्त्रिकी" शब्द १९६८ में एक सम्मलेन में प्रयोग में लाया गया था, लेकिन जिन समस्याओं को ये संबोधित करता है वो बहुत पहले की है। तन्त्रांश अभियान्त्रिकी का इतिहास जटिल रूप से संगणक हार्डवेयर और संगणक तन्त्रांश के इतिहासों से गुथा हुआ है।
 सन् १९४१ में जब प्रथम डिजीटल संगणक अस्तित्व में आया, तब उसे चलाने वाले अनुदेश एक यन्त्र में होते थे जो तारो द्बारा संगणक से जुड़ा होता था। लेकिन शीघ्र ही व्यवसायियो ने ये अनुभव किया की ये ख़ाका अधिक लचीला नहीं है और तब "संग्रहित निर्देश संरचना" या वॉन निउमन स्थापत्य का विकास हुआ।
-१९५० से प्रोग्रामिंग भाषाएँ विकसित होने लगीं और ये भी मतिहीनता की और एक महत्वपूर्ण बढ़त थी। फौरट्रैन, अलगोल और कोबोल जैसी प्रमुख भाषाएँ १९५० के अंतिम वर्षों में आई जो वैज्ञानिक, प्रतीकगणितीय और व्यावसायिक समस्याओं को सुलझाने के लिया बनी थी।सॉफ्टवेयर इंजीनियरिंग (SWE) एक व्यवस्थित विधि में सॉफ्टवेयर के विकास के लिए इंजीनियरिंग का अनुप्रयोग है। [1] [2] [3]
+१९५० से प्रोग्रामिंग भाषाएँ विकसित होने लगीं और ये भी मतिहीनता की और एक महत्वपूर्ण बढ़त थी। फौरट्रैन, अलगोल और कोबोल जैसी प्रमुख भाषाएँ १९५० के अंतिम वर्षों में आई जो वैज्ञानिक, प्रतीकगणितीय और व्यावसायिक समस्याओं को सुलझाने के लिया बनी थी।
-सामग्री [छुपाने के]
-ज्ञात परिभाषाएँ
-निर्माण और फुर्तीली विधियों में तकनीक refactor
-इतिहास
-subdisciplines
-शिक्षा
-व्यवसाय
-.1 रोजगार
-.2 प्रमाणीकरण
-.3 वैश्वीकरण का प्रभाव
-संबंधित फ़ील्ड्स
-विवाद
-.1 परिभाषा पर
-.2 आलोचना
-यह भी देखें
-नोट्स
-संदर्भ
-आगे पढ़ने
-बाह्य लिंक
-ज्ञात परिभाषाएँ [संपादित करें]
-सॉफ्टवेयर इंजीनियरिंग के ठेठ औपचारिक परिभाषाओं में शामिल हैं:
-"अनुसंधान, डिजाइन, विकास, और ऑपरेटिंग सिस्टम-स्तर सॉफ़्टवेयर, संकलक, और चिकित्सा, औद्योगिक, सैन्य, संचार, एयरोस्पेस, व्यावसायिक, वैज्ञानिक, के लिए नेटवर्क वितरण सॉफ्टवेयर और जनरल कम्प्यूटिंग अनुप्रयोगों का परीक्षण"-ब्यूरो श्रम सांख्यिकी [प्रशस्ति पत्र की जरूरत]
-"वैज्ञानिक और प्रौद्योगिकीय ज्ञान, विधियों, और अनुभव के व्यवस्थित अनुप्रयोग डिजाइन, कार्यान्वयन, परीक्षण और सॉफ्टवेयर के प्रलेखन के लिए"-श्रम सांख्यिकी के ब्यूरो-IEEE सिस्टम और सॉफ्टवेयर इंजीनियरिंग - शब्दावली [4]
-"एक व्यवस्थित, अनुशासित, मात्रात्मक दृष्टिकोण के अनुप्रयोग विकास, संचालन, और सॉफ्टवेयर के रखरखाव के लिए"-IEEE मानक शब्दावली के सॉफ्टवेयर इंजीनियरिंग शब्दावली [5]
-"सॉफ्टवेयर उत्पादन के सभी पहलुओं के साथ संबंध है एक इंजीनियरिंग अनुशासन है कि"-इयान Sommerville [6]
-"स्थापना और इंजीनियरिंग के सिद्धांतों के क्रम में आर्थिक रूप से ध्वनि का उपयोग सॉफ्टवेयर है कि विश्वसनीय है और काम करता है कुशलता से असली मशीनों पर प्राप्त करें"-फ्रिट्ज Bauer [7]
-बिल्ड और refactor तकनीक में चंचल तरीके [संपादित करें]
-यह सभी वर्गों पर पूर्ण नियंत्रण करने के लिए टीम के सभी सदस्यों की अनुमति का सिद्धांत है और सभी इंटरफ़ेस पर हर समय। एक टीम के सदस्य एक सुविधा है, और नहीं इंटरफेस के एक सेट को लागू करने पर ध्यान दिया जाएगा। यह है क्योंकि एक सुविधा कई वर्गों और इंटरफ़ेस से अधिक अवधि सकता है, और एक वर्ग के लिए एक विशेषता encapsulating डिजाइन नीचे भंग हो सकता है। एक यह फ़ंक्शन इंटरफ़ेस और जब एक वर्ग के लिए एक लग रहा है जोड़ने के लिए की जरूरत है, और डुप्लिकेट कार्य के मामलों में, एक बनाता है एक समारोह का नाम बदलने की अनुमति है। इस भाग के क्या बिल्डिंग कहा जाता है। एक एक स्प्रिंट जमघट में उदाहरण के लिए, एक बनाने पर ध्यान केंद्रित करने के लिए उपयोग कर सकते हैं।
-इस संदर्भ में refactoring समान कार्य खोजने पर केंद्रित है और उन्हें एक साथ मर्ज करें, या एक निर्णय चर जोड़ें कार्य कार्य करता है कि इस तरह के रूप में यदि एक दो कार्य यह सुविधाजनक लगता है।
-इस तकनीक मानता है कि एक UML डिजाइन करने के लिए कुछ है कि वास्तव में काम कर सकते हैं अनुरूप नहीं हो सकता है, और कि एक टीम कार्य अन्य इंटरफेस और कक्षाओं से एक वास्तव में जरूरत की कमी के कारण डिज़ाइन बदल सकते हैं।
-इतिहास [संपादित करें]
-मुख्य लेख: सॉफ्टवेयर इंजीनियरी का इतिहास
-जब पहला डिजिटल कंप्यूटर दर्शन १९४० के दशक में, [8] उन्हें संचालित करने के लिए निर्देश मशीन में दूसरे से जुड़े थे। चिकित्सकों को जल्दी एहसास हुआ कि इस डिजाइन लचीला नहीं था और "भंडारित क्रमादेश संरचना" या वॉन Neumann आर्किटेक्चर के साथ आया था। इस प्रकार "हार्डवेयर" और "सॉफ्टवेयर" के बीच विभाजन अमूर्त कंप्यूटिंग की जटिलता के साथ सौदा करने के लिए इस्तेमाल किया जा रहा है के साथ शुरू हुआ।
-सन् १९५० के दशक में [प्रशस्ति पत्र की जरूरत] प्रकट करने के लिए प्रोग्रामिंग भाषाओं शुरू कर दिया और यह भी अमूर्त में एक और बड़ा कदम था। फोरट्रान, एल्गॉल, और कोबोल जैसी प्रमुख भाषाएँ क्रमश: वैज्ञानिक, एल्गोरिथम, और व्यावसायिक समस्याओं के साथ सौदा करने के लिए देर से 1950 के दशक में रिलीज़ किया गया था। Edsger डब्ल्यू Dijkstra अपने लाभदायक पत्र लिखा था, "जाने के लिए बयान माना जाता हानिकारक है", [9] 1968 में और डेविड Parnas प्रतिरूपकता और प्रोग्रामर सॉफ्टवेयर प्रणाली की बढ़ती जटिलता के साथ निपटने में मदद करने के लिए [10] 1972 में छुपा जानकारी की कुंजी अवधारणा शुरू की।
-शब्द "सॉफ्टवेयर इंजीनियरिंग" की उत्पत्ति विभिन्न स्रोतों को जिम्मेदार ठहराया गया है, लेकिन यह 1968 में दुनिया का पहला सम्मेलन सॉफ्टवेयर इंजीनियरिंग के लिए एक शीर्षक के रूप में इस्तेमाल किया गया था, प्रायोजित और नाटो द्वारा मदद की। सम्मेलन जो सॉफ्टवेयर इंजीनियरिंग के आवेदन में जमीन के लिए उत्तम आचरण को परिभाषित करने पर सहमत हुए सॉफ्टवेयर पर अंतरराष्ट्रीय विशेषज्ञों ने भाग लिया था। सम्मेलन का परिणाम निर्धारित करता है कैसे सॉफ्टवेयर विकसित किया जाना चाहिए एक रिपोर्ट है। मूल रिपोर्ट सार्वजनिक रूप से उपलब्ध है। [11]
-सॉफ्टवेयर इंजीनियरिंग के अनुशासन गरीब गुणवत्ता सॉफ्टवेयर का पता, समय और बजट नियंत्रण से अधिक परियोजनाओं को मिल और सॉफ्टवेयर व्यवस्थित, कड़ाई, मात्रा, समय, बजट, और विनिर्देशन के भीतर बनाया गया है कि यह सुनिश्चित करने के लिए बनाया गया था। [12] इंजीनियरिंग पहले से ही इन सभी समस्याओं को हल करता है, इसलिए करने के लिए सॉफ्टवेयर इंजीनियरिंग में प्रयोग किया जाता एक ही सिद्धांत लागू किया जा सकता। समय पर सॉफ्टवेयर के लिए सर्वोत्तम प्रथाओं की व्यापक कमी के एक "सॉफ्टवेयर संकट" के रूप में माना जाता था। [13] [14] [15]
-बैरी डब्ल्यू Boehm क्षेत्र के लिए कई प्रमुख अग्रिमों उनकी 1981 पुस्तक, 'सॉफ्टवेयर इंजीनियरिंग अर्थशास्त्र' में प्रलेखित किया गया। [16] ये मानव वर्षों का कार्य टी, स्रोत कोड (SLOC) की लाइनों के लिए में अपने रचनात्मक लागत मॉडल (जो एक कार्यक्रम के लिए सॉफ्टवेयर विकास के प्रयास से संबंधित COCOMO), शामिल हैं। {\displaystyle T=k*(SLOC)^{(1+x)}} T=k*(SLOC)^{(1+x)} पुस्तक साठ तीन softwa का विश्लेषण करती है
 softwere are good fo cumputers