सामग्री पर जाएँ

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

मुक्त ज्ञानकोश विकिपीडिया से
(सॉफ्टवेयर डेवलपमेण्ट से अनुप्रेषित)

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

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

सॉफ्टवेयर विकास में कई उपकरण शामिल होते हैं जिनमें शामिल हैं: कंपाइलर, एकीकृत विकास परिवेश (IDE), संस्करण नियंत्रण, कंप्यूटर-एडेड सॉफ्टवेयर इंजीनियरिंग, और शब्द संसाधक।

विकास प्रयास के लिए उपयोग की जाने वाली प्रक्रिया का विवरण अलग-अलग होता है। यह प्रक्रिया एक औपचारिक, प्रलेखित मानक तक सीमित हो सकती है, या इसे विकास प्रयास के लिए अनुकूलित और उभरती हुई बनाया जा सकता है। प्रक्रिया अनुक्रमिक हो सकती है, जिसमें प्रत्येक मुख्य चरण (यानी, डिजाइन, कार्यान्वयन और परीक्षण) अगले के शुरू होने से पहले पूरा किया जाता है, लेकिन एक पुनरावृत्ति दृष्टिकोण (iterative approach) – जहाँ छोटे पहलुओं को अलग से डिजाइन, कार्यान्वित और परीक्षण किया जाता है – जोखिम और लागत को कम कर सकता है और गुणवत्ता बढ़ा सकता है।

कार्यप्रणालियाँ

[संपादित करें]
विकासवादी प्रोटोटाइप मॉडल का फ्लोचार्ट, जो एक पुनरावृत्ति विकास मॉडल है[2]

विभिन्न तकनीकी, संगठनात्मक, परियोजना और टीम के विचारों के आधार पर उपलब्ध प्रत्येक कार्यप्रणाली विशिष्ट प्रकार की परियोजनाओं के लिए सबसे उपयुक्त है।[3]

  • सबसे सरल कार्यप्रणाली "कोड और फिक्स" (code and fix) है, जिसका उपयोग आमतौर पर एक छोटी परियोजना पर काम करने वाले एकल प्रोग्रामर द्वारा किया जाता है। प्रोग्राम के उद्देश्य पर संक्षेप में विचार करने के बाद, प्रोग्रामर इसे कोड करता है और यह देखने के लिए चलाता है कि क्या यह काम करता है। जब वे काम पूरा कर लेते हैं, तो उत्पाद जारी कर दिया जाता है। यह कार्यप्रणाली प्रोटोटाइप के लिए उपयोगी है लेकिन इसका उपयोग अधिक विस्तृत कार्यक्रमों के लिए नहीं किया जा सकता है।[4]
  • टॉप-डाउन वाटरफॉल मॉडल में, व्यवहार्यता, विश्लेषण, डिजाइन, विकास, गुणवत्ता आश्वासन, और कार्यान्वयन उसी क्रम में क्रमिक रूप से होते हैं। इस मॉडल में अगले चरण के शुरू होने से पहले एक चरण के पूरा होने की आवश्यकता होती है, जिससे देरी होती है, और यदि आवश्यक हो तो पिछले चरणों को संशोधित करना असंभव हो जाता है।[5][6][7]
  • पुनरावृत्ति प्रक्रियाओं के साथ ये चरण बेहतर लचीलेपन, दक्षता और अधिक यथार्थवादी समय-सारणी के लिए एक-दूसरे के साथ गुंथे होते हैं। एक ही बार में परियोजना को पूरा करने के बजाय, कोई एक समय में एक घटक के साथ अधिकांश चरणों से गुजर सकता है। पुनरावृत्ति विकास विकासकर्ताओं को सबसे महत्वपूर्ण विशेषताओं को प्राथमिकता देने की अनुमति देता है, जिससे जरूरत पड़ने पर कम प्राथमिकता वाली विशेषताओं को बाद में छोड़ा जा सकता है।[6][8] एजाइल एक लोकप्रिय पद्धति है, जो मूल रूप से छोटी या मध्यम आकार की परियोजनाओं के लिए अभिप्रेत थी, जो विकासकर्ताओं को उन विशेषताओं पर अधिक नियंत्रण देने पर केंद्रित है जिन पर वे काम करते हैं ताकि समय या लागत बढ़ने के जोखिम को कम किया जा सके।[9] एजाइल के व्युत्पन्नों में एक्सट्रीम प्रोग्रामिंग और स्क्रम शामिल हैं।[9] मुक्त स्रोत सॉफ्टवेयर विकास आमतौर पर स्वयंसेवक योगदानकर्ताओं के वितरित नेटवर्क पर निर्भरता के कारण समवर्ती डिजाइन, कोडिंग और परीक्षण के साथ एजाइल पद्धति का उपयोग करता है।[10]
  • एजाइल से परे, कुछ कंपनियां सूचना प्रौद्योगिकी (IT) संचालन को सॉफ्टवेयर विकास के साथ एकीकृत करती हैं, जिसे डेव ऑप्स या डेव-सेक-ऑप्स (DevSecOps) कहा जाता है जिसमें कंप्यूटर सुरक्षा शामिल है।[11] डेवऑप्स में निरंतर विकास, परीक्षण, संस्करण नियंत्रण प्रणाली में नए कोड का निरंतर एकीकरण, नए कोड का निरंतर परिनियोजन, और कभी-कभी ग्राहकों को कोड का निरंतर वितरण शामिल है।[12] इस एकीकरण का उद्देश्य आईटी सेवाओं को अधिक तेज़ी से और कुशलता से वितरित करना है।[11]

कई प्रोग्रामिंग पद्धतियों में एक और ध्यान देने योग्य बात यह है कि सुरक्षा कमजोरियों और बग जैसी समस्याओं को जितनी जल्दी हो सके पकड़ने का प्रयास किया जाए (शिफ्ट-लेफ्ट परीक्षण), ताकि उन्हें ट्रैक करने और ठीक करने की लागत कम हो सके।[13]

2009 में, यह अनुमान लगाया गया था कि 32% सॉफ्टवेयर परियोजनाएं समय पर, बजट के भीतर और पूर्ण कार्यक्षमता के साथ वितरित की गईं। अतिरिक्त 44% वितरित तो की गईं, लेकिन उनमें कम से कम एक विशेषता की कमी थी। शेष 24% रिलीज से पहले ही रद्द कर दी गईं।[14]

जीवन चक्र

[संपादित करें]

सॉफ्टवेयर विकास जीवन चक्र सॉफ्टवेयर विकसित करने की प्रक्रिया के विशिष्ट चरणों का वर्णन करता है।[15]

व्यवहार्यता

[संपादित करें]

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

विश्लेषण

[संपादित करें]

सॉफ्टवेयर विश्लेषण सॉफ्टवेयर की व्यावसायिक आवश्यकताओं को समझने के लिए आवश्यकता विश्लेषण (requirements analysis) से शुरू होता है।[19] आवश्यकताओं की पहचान के लिए चुनौतियां यह हैं कि वर्तमान या संभावित उपयोगकर्ताओं की अलग-अलग और असंगत आवश्यकताएं हो सकती हैं, वे अपनी आवश्यकताओं को नहीं समझ सकते हैं, और सॉफ्टवेयर विकास की प्रक्रिया के दौरान अपनी आवश्यकताओं को बदल सकते हैं।[20] अंततः, विश्लेषण का परिणाम उत्पाद के लिए एक विस्तृत विवरण होता है जिससे विकासकर्ता काम कर सकते हैं। सॉफ्टवेयर विश्लेषक अक्सर लागत-प्रभावशीलता, दक्षता और विश्वसनीयता बढ़ाने के लिए परियोजना को छोटी वस्तुओं, घटकों में विभाजित (decompose) करते हैं जिन्हें फिर से उपयोग किया जा सकता है।[19] परियोजना को विभाजित करने से एक मल्टी-थ्रेडेड कार्यान्वयन सक्षम हो सकता है जो मल्टीप्रोसेसर कंप्यूटरों पर काफी तेजी से चलता है।[21]

सॉफ्टवेयर विकास के विश्लेषण और डिजाइन चरणों के दौरान, ग्राहक की आवश्यकताओं को उन टुकड़ों में तोड़ने के लिए अक्सर संरचित विश्लेषण (structured analysis) का उपयोग किया जाता है जिन्हें सॉफ्टवेयर प्रोग्रामर द्वारा कार्यान्वित किया जा सकता है।[22] प्रोग्राम के अंतर्निहित तर्क को डेटा-प्रवाह आरेख, डेटा शब्दकोश, छद्म कोड (pseudocode), अवस्था आरेख, और/या एंटीटी रिलेशनशिप डायग्राम में दर्शाया जा सकता है।[23] यदि परियोजना में किसी पुराने सॉफ्टवेयर (legacy software) का हिस्सा शामिल है जिसका मॉडल तैयार नहीं किया गया है, तो यह सुनिश्चित करने में मदद के लिए इस सॉफ्टवेयर का मॉडल तैयार किया जा सकता है कि यह नए सॉफ्टवेयर के साथ सही ढंग से शामिल किया गया है।[24]

डिजाइन

[संपादित करें]

डिजाइन में सॉफ्टवेयर के कार्यान्वयन के बारे में विकल्प शामिल होते हैं, जैसे कि किस प्रोग्रामिंग भाषा और डेटाबेस सॉफ्टवेयर का उपयोग करना है, या हार्डवेयर और नेटवर्क संचार कैसे व्यवस्थित किया जाएगा। डिजाइन पुनरावृत्त (iterative) हो सकता है जिसमें परीक्षण और त्रुटि की प्रक्रिया में उपयोगकर्ताओं से उनकी आवश्यकताओं के बारे में परामर्श किया जाता है। डिजाइन में अक्सर वे लोग शामिल होते हैं जो डेटाबेस डिजाइन, स्क्रीन आर्किटेक्चर और सर्वर तथा अन्य हार्डवेयर के प्रदर्शन जैसे पहलुओं के विशेषज्ञ होते हैं।[19] डिजाइनर अक्सर सॉफ्टवेयर की कार्यक्षमता में पैटर्न खोजने का प्रयास करते हैं ताकि अलग-अलग मॉड्यूल बनाए जा सकें जिन्हें ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के साथ पुन: उपयोग किया जा सके। इसका एक उदाहरण मॉडल दृष्टि नियंत्रक (MVC) है, जो एक ग्राफिकल यूजर इंटरफेस और बैकएंड के बीच का इंटरफेस है।[25]

प्रोग्रामिंग

[संपादित करें]

सॉफ्टवेयर विकास की केंद्रीय विशेषता उस सॉफ्टवेयर को बनाना और समझना है जो वांछित कार्यक्षमता को लागू करता है।[26] कोड लिखने के लिए विभिन्न रणनीतियाँ हैं। एकजुट (Cohesive) सॉफ्टवेयर में विभिन्न घटक होते हैं जो एक-दूसरे से स्वतंत्र होते हैं।[19] कपलिंग (Coupling) विभिन्न सॉफ्टवेयर घटकों का परस्पर संबंध है, जिसे अवांछनीय माना जाता है क्योंकि यह रखरखाव की कठिनाई को बढ़ाता है।[27] अक्सर, सॉफ्टवेयर प्रोग्रामर उद्योग के सर्वोत्तम अभ्यासों का पालन नहीं करते हैं, जिसके परिणामस्वरूप ऐसा कोड बनता है जो अक्षम होता है, समझना मुश्किल होता है, या इसकी कार्यक्षमता पर दस्तावेजीकरण की कमी होती है।[28] समय सीमा की उपस्थिति में इन मानकों के टूटने की संभावना विशेष रूप से अधिक होती है।[29] परिणामस्वरूप, कोड का परीक्षण, डिबगिंग और संशोधन करना बहुत कठिन हो जाता है। कोड रीफैक्टरिंग (Code refactoring), उदाहरण के लिए, कोड में अधिक टिप्पणियां जोड़ना, कोड की समझ में सुधार करने के लिए एक समाधान है।[30]

परीक्षण

[संपादित करें]

परीक्षण यह सुनिश्चित करने की प्रक्रिया है कि कोड सही ढंग से और बिना किसी त्रुटि के निष्पादित हो। डिबगिंग प्रत्येक सॉफ्टवेयर विकासक द्वारा अपने स्वयं के कोड पर यह पुष्टि करने के लिए की जाती है कि कोड वही करता है जो वह करने का इरादा रखता है। विशेष रूप से, यह महत्वपूर्ण है कि सॉफ्टवेयर सभी इनपुट पर निष्पादित हो, भले ही परिणाम गलत हो।[31] अन्य विकासकर्ताओं द्वारा कोड समीक्षा (Code reviews) का उपयोग अक्सर परियोजना में जोड़े गए नए कोड की जांच करने के लिए किया जाता है, और कुछ अनुमानों के अनुसार परीक्षण पूरा होने के बाद बचे बग की संख्या को काफी कम कर देता है।[32] एक बार कोड सबमिट हो जाने के बाद, गुणवत्ता आश्वासन – अधिकांश बड़ी कंपनियों के लिए गैर-प्रोग्रामर का एक अलग विभाग – पूरे सॉफ्टवेयर उत्पाद की सटीकता का परीक्षण करता है। मूल सॉफ्टवेयर आवश्यकताओं से प्राप्त स्वीकृति परीक्षण इसके लिए एक लोकप्रिय उपकरण हैं।[31] गुणवत्ता परीक्षण में अक्सर स्ट्रेस और लोड चेकिंग (क्या सॉफ्टवेयर इनपुट या उपयोग के भारी स्तरों के लिए मजबूत है), एकीकरण परीक्षण (यह सुनिश्चित करने के लिए कि सॉफ्टवेयर अन्य सॉफ्टवेयर के साथ पर्याप्त रूप से एकीकृत है), और संगतता परीक्षण (विभिन्न ऑपरेटिंग सिस्टम या ब्राउज़र पर सॉफ्टवेयर के प्रदर्शन को मापना) भी शामिल है।[31] जब कोड से पहले परीक्षण लिखे जाते हैं, तो इसे परीक्षण-संचालित विकास (test-driven development) कहा जाता है।[33]

उत्पादन

[संपादित करें]

उत्पादन वह चरण है जिसमें सॉफ्टवेयर को अंतिम उपयोगकर्ता के लिए तैनात किया जाता है।[34] उत्पादन के दौरान, विकासक उपयोगकर्ताओं के लिए तकनीकी सहायता संसाधन बना सकता है[35][34] या उन बग और त्रुटियों को ठीक करने की प्रक्रिया बना सकता है जिन्हें पहले नहीं पकड़ा गया था। यदि उपयोगकर्ता की ज़रूरतें बदल गई हैं या गलत समझी गई थीं, तो पहले के विकास चरणों में वापसी भी हो सकती है।[34]

कार्यकर्ता

[संपादित करें]

सॉफ्टवेयर विकास सॉफ्टवेयर विकासकों द्वारा किया जाता है, जो आमतौर पर एक टीम में काम करते हैं। टीम के सदस्यों के बीच कुशल संचार सफलता के लिए आवश्यक है। यह अधिक आसानी से प्राप्त किया जा सकता है यदि टीम छोटी हो, एक साथ काम करने की आदी हो, और एक-दूसरे के पास स्थित हो।[36] संचार विकास के प्रारंभिक चरण में समस्याओं की पहचान करने और प्रयासों के दोहराव से बचने में भी मदद करता है। कई विकास परियोजनाएं यह सुनिश्चित करके केवल एक कर्मचारी द्वारा रखी गई आवश्यक जानकारी खोने के जोखिम से बचती हैं कि कई कार्यकर्ता प्रत्येक घटक से परिचित हों।[37] सॉफ्टवेयर विकास में विभिन्न क्षेत्रों के पेशेवर शामिल होते हैं, न केवल सॉफ्टवेयर प्रोग्रामर बल्कि उत्पाद प्रबंधक भी जो उत्पाद के लिए रणनीति और तकनीकी रोडमैप निर्धारित करते हैं,[38] परीक्षण, दस्तावेजीकरण लेखन, ग्राफ़िक डिज़ाइन, उपयोक्ता सहायता, विपणन, और धन उगाहने में विशेषज्ञता रखने वाले व्यक्ति। हालांकि मालिकाना (proprietary) सॉफ्टवेयर के कार्यकर्ताओं को भुगतान किया जाता है, मुक्त स्रोत सॉफ्टवेयर में अधिकांश योगदानकर्ता स्वयंसेवक होते हैं।[39] वैकल्पिक रूप से, उन्हें उन कंपनियों द्वारा भुगतान किया जा सकता है जिनका व्यवसाय मॉडल सॉफ्टवेयर बेचने में शामिल नहीं है, बल्कि कुछ और – जैसे सेवाएँ और मुक्त स्रोत सॉफ्टवेयर में संशोधन।[40]

मॉडल और उपकरण

[संपादित करें]

कंप्यूटर-एडेड सॉफ्टवेयर इंजीनियरिंग

[संपादित करें]

कंप्यूटर-एडेड सॉफ्टवेयर इंजीनियरिंग (CASE) सॉफ्टवेयर विकास के आंशिक स्वचालन के उपकरण हैं।[41] CASE डिजाइनरों को प्रोग्राम के तर्क को स्केच करने में सक्षम बनाता है, चाहे वह लिखा जाना हो, या पहले से मौजूद हो ताकि इसे नए कोड के साथ एकीकृत करने या इसकी रिवर्स इंजीनियरिंग (उदाहरण के लिए, प्रोग्रामिंग भाषा बदलने के लिए) करने में मदद मिल सके।[42]

दस्तावेजीकरण

[संपादित करें]

दस्तावेजीकरण दो रूपों में आता है जिन्हें आमतौर पर अलग रखा जाता है – एक सॉफ्टवेयर विकासकों के लिए अभिप्रेत है, और दूसरा अंतिम उपयोगकर्ता को सॉफ्टवेयर का उपयोग करने में मदद करने के लिए उपलब्ध कराया जाता है।[43][44] अधिकांश विकासक दस्तावेजीकरण प्रत्येक फाइल, क्लास, और विधि के लिए कोड टिप्पणियों के रूप में होता है जो एपीआई (API) को कवर करते हैं—सॉफ्टवेयर के टुकड़े को दूसरे द्वारा कैसे एक्सेस किया जा सकता है—और अक्सर कार्यान्वयन विवरण भी शामिल होते हैं।[45] यह दस्तावेजीकरण नए विकासकों के लिए परियोजना को समझने में सहायक होता है जब वे इस पर काम करना शुरू करते हैं।[46] एजाइल विकास में, दस्तावेजीकरण अक्सर कोड के साथ ही लिखा जाता है।[47] उपयोगकर्ता दस्तावेजीकरण अधिक बार तकनीकी लेखकों द्वारा लिखा जाता है।[48]

प्रयास अनुमान

[संपादित करें]

व्यवहार्यता चरण में और उत्पाद को समय पर और बजट के भीतर वितरित करने में सटीक अनुमान महत्वपूर्ण है। अनुमान उत्पन्न करने की प्रक्रिया अक्सर परियोजना प्रबंधक द्वारा सौंपी जाती है।[49] चूंकि प्रयास अनुमान सीधे पूर्ण अनुप्रयोग के आकार से संबंधित है, इसलिए यह आवश्यकताओं में सुविधाओं के जुड़ने से दृढ़ता से प्रभावित होता है—जितनी अधिक आवश्यकताएं होंगी, विकास लागत उतनी ही अधिक होगी। कार्यक्षमता से संबंधित नहीं पहलू, जैसे कि सॉफ्टवेयर विकासकों का अनुभव और कोड पुन: प्रयोज्यता, भी अनुमान में विचार करने के लिए आवश्यक हैं।[50] 2019 तक, सॉफ्टवेयर विकास के लिए समय और संसाधनों की मात्रा का अनुमान लगाने के अधिकांश उपकरण पारंपरिक अनुप्रयोगों के लिए डिज़ाइन किए गए थे और वेब अनुप्रयोगों या मोबाइल अनुप्रयोगों पर लागू नहीं होते हैं।[51]

एकीकृत विकास परिवेश

[संपादित करें]
अंजुता, गनोम (GNOME) वातावरण के लिए एक C और C++ IDE

एक एकीकृत विकास परिवेश (IDE) एक साधारण टेक्स्ट एडिटर की तुलना में बढ़ी हुई विशेषताओं के साथ सॉफ्टवेयर विकास का समर्थन करता है।[52] IDE में अक्सर स्वचालित कंपाइलिंग, त्रुटियों की सिंटैक्स हाइलाइटिंग,[53] डिबगिंग सहायता,[54] संस्करण नियंत्रण के साथ एकीकरण, और परीक्षणों का अर्ध-स्वचालन शामिल होता है।[52]

संस्करण नियंत्रण

[संपादित करें]

सॉफ्टवेयर में किए गए परिवर्तनों को प्रबंधित करने का एक लोकप्रिय तरीका संस्करण नियंत्रण (Version control) है। जब भी कोई नया संस्करण चेक-इन किया जाता है, तो सॉफ्टवेयर सभी संशोधित फाइलों का एक बैकअप सहेजता है। यदि कई प्रोग्रामर एक साथ सॉफ्टवेयर पर काम कर रहे हैं, तो यह उनके कोड परिवर्तनों के विलय (merging) का प्रबंधन करता है। सॉफ्टवेयर उन मामलों को उजागर करता है जहां परिवर्तनों के दो सेटों के बीच संघर्ष होता है और प्रोग्रामर को संघर्ष को ठीक करने की अनुमति देता है।[55]

व्यू मॉडल

[संपादित करें]
व्यू और दृष्टिकोण का TEAF मैट्रिक्स

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

दृष्टिकोणों और दृश्यों का उद्देश्य मानव इंजीनियरों को बहुत जटिल प्रणालियों को समझने और समस्या के तत्वों को विशेषज्ञता के डोमेन के आसपास व्यवस्थित करने में सक्षम बनाना है। भौतिक रूप से गहन प्रणालियों की इंजीनियरिंग में, दृष्टिकोण अक्सर इंजीनियरिंग संगठन के भीतर क्षमताओं और जिम्मेदारियों के अनुरूप होते हैं।[56]

फिटनैस फलन

[संपादित करें]

फिटनैस फलन (Fitness functions) यह सुनिश्चित करने के लिए स्वचालित और वस्तुनिष्ठ परीक्षण हैं कि नए विकास स्थापित बाधाओं, जांच और अनुपालन नियंत्रणों से विचलित न हों।[57]

बौद्धिक संपदा

[संपादित करें]

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

संदर्भ

[संपादित करें]
  1. ↑ डूली 2017, p. 1.
  2. ↑ डूली 2017, p. 12.
  3. ↑ System Development Methodologies for Web-Enabled E-Business: A Customization Framework लिंडा वी. नाइट (डीपॉल यूनिवर्सिटी, यूएसए), थेरेसा ए. स्टीनबैक (डीपॉल यूनिवर्सिटी, यूएसए), और विंस केलन (ब्लू वुल्फ, यूएसए)
  4. ↑ डूली 2017, pp. 8–9.
  5. ↑ डूली 2017, p. 9.
  6. 1 2 लैंगर 2016, pp. 2–3, 5–6.
  7. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 8.
  8. ↑ डूली 2017, p. 11.
  9. 1 2 डूली 2017, p. 13.
  10. ↑ टकर, मोरेली & डी सिल्वा 2011, pp. 41–42.
  11. 1 2 विष्णु 2019, pp. 1–2.
  12. ↑ Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). "Problems, causes and solutions when adopting continuous delivery—A systematic literature review" [निरंतर वितरण को अपनाते समय समस्याएं, कारण और समाधान—एक व्यवस्थित साहित्य समीक्षा]. Information and Software Technology [सूचना और सॉफ्टवेयर प्रौद्योगिकी] (अंग्रेज़ी भाषा में). 82: 55–79. डीओआई:10.1016/j.infsof.2016.10.001.
  13. ↑ विंटर्स, मैन्शरेक & राइट 2020, p. 17.
  14. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 6.
  15. ↑ सैफ 2019, pp. 46–47.
  16. ↑ मौरिस 2001, p. 1.10.
  17. ↑ लैंगर 2016, p. 7.
  18. ↑ डूली 2017, pp. 3, 8.
  19. 1 2 3 4 लैंगर 2016, p. 8.
  20. ↑ लैंगर 2016, pp. 2–3.
  21. ↑ डूली 2017, pp. 193–194.
  22. ↑ लैंगर 2016, pp. 103–104.
  23. ↑ लैंगर 2016, pp. 117, 127, 131, 137, 141.
  24. ↑ लैंगर 2016, p. 106.
  25. ↑ डूली 2017, p. 142.
  26. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 31.
  27. ↑ लैंगर 2016, pp. 8–9.
  28. ↑ टकर, मोरेली & डी सिल्वा 2011, pp. 31–32.
  29. ↑ टकर, मोरेली & डी सिल्वा 2011, pp. 34–35.
  30. ↑ टकर, मोरेली & डी सिल्वा 2011, pp. 31–32, 35.
  31. 1 2 3 लैंगर 2016, p. 9.
  32. ↑ डूली 2017, p. 272.
  33. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 9.
  34. 1 2 3 लैंगर 2016, p. 10.
  35. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 37.
  36. ↑ डूली 2017, p. 2.
  37. ↑ विंटर्स, मैन्शरेक & राइट 2020, pp. 30–31.
  38. ↑ "What Does a Product Manager Do? And How to Become One" [एक उत्पाद प्रबंधक क्या करता है? और एक कैसे बनें]. Coursera (अंग्रेज़ी भाषा में). 2025-01-21. अभिगमन तिथि: 2025-05-05.
  39. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 7.
  40. ↑ टकर, मोरेली & डी सिल्वा 2011, pp. 14–15.
  41. ↑ लैंगर 2016, p. 22.
  42. ↑ लैंगर 2016, pp. 108–110, 206.
  43. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 243.
  44. ↑ विंटर्स, मैन्शरेक & राइट 2020, p. 192.
  45. ↑ विंटर्स, मैन्शरेक & राइट 2020, pp. 193–195.
  46. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 143.
  47. ↑ टकर, मोरेली & डी सिल्वा 2011, p. 144.
  48. ↑ विंटर्स, मैन्शरेक & राइट 2020, p. 204.
  49. ↑ सैफ 2019, pp. 50–51.
  50. ↑ सैफ 2019, pp. 52–53.
  51. ↑ सैफ 2019, p. 45.
  52. 1 2 टकर, मोरेली & डी सिल्वा 2011, p. 68.
  53. ↑ डूली 2017, p. 236.
  54. ↑ डूली 2017, p. 239.
  55. ↑ डूली 2017, pp. 246–247.
  56. ↑ एडवर्ड जे. बार्कमियर आदि (2003). Concepts for Automating Systems Integration Archived 25 जनवरी 2017 at the वेबैक मशीन NIST 2003.
  57. ↑ Fundamentals of Software Architecture: An Engineering Approach [सॉफ्टवेयर आर्किटेक्चर के मूल सिद्धांत: एक इंजीनियरिंग दृष्टिकोण] (अंग्रेज़ी भाषा में). O'Reilly Media. 2020. ISBN 978-1492043454.
  58. ↑ लैंगर 2016, pp. 44–45.

आगे और पढ़ें

[संपादित करें]
  • Conde, Dan (2002). Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales [सॉफ्टवेयर उत्पाद प्रबंधन: विचार से उत्पाद तक विपणन से बिक्री तक सॉफ्टवेयर विकास का प्रबंधन] (अंग्रेज़ी भाषा में). Aspatore Books. ISBN 1587622025.
  • Davis, A. M. (2005). Just enough requirements management: Where software development meets marketing [बस पर्याप्त आवश्यकताएं प्रबंधन: जहां सॉफ्टवेयर विकास विपणन से मिलता है] (अंग्रेज़ी भाषा में). Dorset House Publishing Company, Incorporated. ISBN 0932633641.
  • Dooley, John F. (2017). Software Development, Design and Coding: With Patterns, Debugging, Unit Testing, and Refactoring [सॉफ्टवेयर विकास, डिजाइन और कोडिंग: पैटर्न, डिबगिंग, यूनिट टेस्टिंग और रीफैक्टरिंग के साथ] (अंग्रेज़ी भाषा में). Apress. ISBN 978-1-4842-3153-1.
  • Kit, Edward (1992). Software Testing in The Real World [वास्तविक दुनिया में सॉफ्टवेयर परीक्षण] (अंग्रेज़ी भाषा में). Addison-Wesley Professional. ISBN 0201877562.
  • Hasted, Edward (2005). Software That Sells: A Practical Guide to Developing and Marketing Your Software Project [बिकने वाला सॉफ्टवेयर: आपके सॉफ्टवेयर प्रोजेक्ट को विकसित करने और विपणन करने के लिए एक व्यावहारिक गाइड] (अंग्रेज़ी भाषा में). Wiley Publishing. ISBN 0764597833.
  • Hohmann, Luke (2003). Beyond Software Architecture: Creating and Sustaining Winning Solutions [सॉफ्टवेयर आर्किटेक्चर से परे: विजेता समाधान बनाना और बनाए रखना] (अंग्रेज़ी भाषा में). Addison-Wesley Professional. ISBN 0201775948.
  • Horch, John W. (March 1995). "Two Orientations On How To Work With Objects" [वस्तुओं के साथ काम करने के दो झुकाव]. IEEE Software (अंग्रेज़ी भाषा में). 12 (2): 117–118. साँचा:ProQuest.
  • Langer, Arthur M. (2016). Guide to Software Development: Designing and Managing the Life Cycle [सॉफ्टवेयर विकास के लिए गाइड: जीवन चक्र का डिजाइन और प्रबंधन] (अंग्रेज़ी भाषा में). Springer. ISBN 978-1-4471-6799-0.
  • McCarthy, Jim (1995). Dynamics of Software Development [सॉफ्टवेयर विकास की गतिशीलता] (अंग्रेज़ी भाषा में). Microsoft Press. ISBN 1556158238.
  • Morris, Joseph M. (2001). Software industry accounting [सॉफ्टवेयर उद्योग लेखांकन] (अंग्रेज़ी भाषा में) (2nd ed.). John Wiley & Sons. ओसीएलसी 53863959.
  • Rittinghouse, John (2003). Managing Software Deliverables: A Software Development Management Methodology [सॉफ्टवेयर डिलीवरेबल्स का प्रबंधन: एक सॉफ्टवेयर विकास प्रबंधन कार्यप्रणाली] (अंग्रेज़ी भाषा में). Digital Press. ISBN 155558313X.
  • Saif, Syed Mohsin (2019). "Software Effort Estimation for Successful Software Application Development" [सफल सॉफ्टवेयर अनुप्रयोग विकास के लिए सॉफ्टवेयर प्रयास अनुमान]. In Vishnu, Pendyala (ed.). Tools and Techniques for Software Development in Large Organizations: Emerging Research and Opportunities: Emerging Research and Opportunities [बड़े संगठनों में सॉफ्टवेयर विकास के लिए उपकरण और तकनीकें: उभरते शोध और अवसर] (अंग्रेज़ी भाषा में). IGI Global. pp. 45–97. ISBN 978-1-7998-1865-6.
  • Tucker, Allen; Morelli, Ralph; de Silva, Chamindra (2011). Software Development: An Open Source Approach [सॉफ्टवेयर विकास: एक ओपन सोर्स दृष्टिकोण] (अंग्रेज़ी भाषा में). CRC Press. ISBN 978-1-4398-8460-7.
  • Vishnu, Pendyala (2019). "Evolution of Integration, Build, Test, and Release Engineering Into DevOps and to DevSecOps" [डेवऑप्स और डेवसेकऑप्स में एकीकरण, बिल्ड, टेस्ट और रिलीज इंजीनियरिंग का विकास]. In Vishnu, Pendyala (ed.). Tools and Techniques for Software Development in Large Organizations: Emerging Research and Opportunities: Emerging Research and Opportunities [बड़े संगठनों में सॉफ्टवेयर विकास के लिए उपकरण और तकनीकें: उभरते शोध और अवसर] (अंग्रेज़ी भाषा में). IGI Global. pp. 1–20. ISBN 978-1-7998-1865-6.
  • Wiegers, Karl E. (2005). More About Software Requirements: Thorny Issues and Practical Advice [सॉफ्टवेयर आवश्यकताओं के बारे में अधिक: कांटेदार मुद्दे और व्यावहारिक सलाह] (अंग्रेज़ी भाषा में). Microsoft Press. ISBN 0735622671.
  • Winters, Titus; Manshreck, Tom; Wright, Hyrum (2020). Software Engineering at Google: Lessons Learned from Programming Over Time [गूगल में सॉफ्टवेयर इंजीनियरिंग: समय के साथ प्रोग्रामिंग से सीखे गए सबक] (अंग्रेज़ी भाषा में). O'Reilly Media, Inc. ISBN 978-1-4920-8276-7.
  • Wysocki, Robert K. (2006). Effective Software Project Management [प्रभावी सॉफ्टवेयर परियोजना प्रबंधन] (अंग्रेज़ी भाषा में). Wiley. ISBN 0764596365.

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

[संपादित करें]
  • विकिमीडिया कॉमन्स पर Software development से सम्बन्धित मीडिया

साँचा:Software engineering साँचा:Computer science

"https://hi.wikipedia.org/w/index.php?title=सॉफ्टवेयर_विकास&oldid=6577518" से प्राप्त