सॉफ्टवेयर विकास प्रक्रिया: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(23 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Short description|Process by which software is developed}}
{{Use American English|date=April 2022}}
{{software development process|मूल गतिविधियां}}
[[सॉफ्टवेयर इंजीनियरिंग]] में, सॉफ़्टवेयर विकास प्रक्रिया [[सॉफ्टवेर डिज़ाइन]] या सॉफ़्टवेयर उत्पाद प्रबंधन को उत्तम बनाने के लिए सॉफ़्टवेयर विकास कार्य को छोटे, समानांतर, या अनुक्रमिक चरणों या उप-प्रक्रियाओं में विभाजित करने की प्रक्रिया है। इसे [[सॉफ्टवेयर डेवलपमेंट|सॉफ्टवेयर विकास]] जीवन चक्र (एसडीएलसी) के रूप में भी जाना जाता है। कार्यप्रणाली में विशिष्ट [[प्रदेय]] एवं कलाकृतियों की पूर्व-परिभाषा सम्मिलित  हो सकती है जो किसी अनुप्रयोग को विकसित करने या बनाए रखने के लिए प्रोजेक्ट समहू द्वारा बनाई एवं सम्पूर्ण की जाती हैं।<ref name=CMS08/>


अधिकांश आधुनिक विकास प्रक्रियाओं को क्षणिक सॉफ्टवेयर विकास के रूप में अस्पष्ट रूप से वर्णित किया जा सकता है। अन्य पद्धतियों में [[झरना मॉडल]], [[सॉफ्टवेयर प्रोटोटाइप|सॉफ्टवेयर प्रोटोटाइपिंग]], [[पुनरावृत्त और वृद्धिशील विकास|पुनरावृत्त एवं वृद्धिशील विकास]], [[सर्पिल विकास]], तीव्र अनुप्रयोग विकास एवं [[चरम कार्यक्रम|अंतिम कार्यक्रम]] सम्मिलित हैं। जीवन-चक्र मॉडल को कभी-कभी कार्यप्रणालियों की श्रेणी के लिए अधिक सामान्य शब्द माना जाता है एवं विशिष्ट संगठन द्वारा चयनित की गई विशिष्ट प्रक्रिया को संदर्भित करने के लिए सॉफ़्टवेयर विकास प्रक्रिया को अधिक विशिष्ट शब्द माना जाता है। उदाहरण के लिए, कई विशिष्ट सॉफ़्टवेयर विकास प्रक्रियाएँ हैं जो सर्पिल जीवन-चक्र मॉडल में उपयुक्त होती हैं। क्षेत्र को प्रायः [[सिस्टम विकास जीवन चक्र|प्रणाली विकास जीवन चक्र]] का सबसेट माना जाता है।
 
[[सॉफ्टवेयर इंजीनियरिंग]] में, '''सॉफ़्टवेयर विकास प्रक्रिया'''  सॉफ्टवेयर डिज़ाइन या सॉफ़्टवेयर उत्पाद प्रबंधन को उत्तम बनाने के लिए सॉफ़्टवेयर विकास कार्य को छोटे, समानांतर, या अनुक्रमिक चरणों या उप-प्रक्रियाओं में विभाजित करने की प्रक्रिया है। इसे [[सॉफ्टवेयर डेवलपमेंट|सॉफ्टवेयर विकास]] जीवन चक्र (एसडीएलसी) के रूप में भी जाना जाता है। कार्यप्रणाली में विशिष्ट [[प्रदेय]] एवं कलाकृतियों की पूर्व-परिभाषा सम्मिलित हो सकती है जो किसी अनुप्रयोग को विकसित करने या बनाए रखने के लिए प्रोजेक्ट समहू द्वारा बनाई एवं सम्पूर्ण की जाती हैं।<ref name=CMS08/>
 
अधिकांश आधुनिक विकास प्रक्रियाओं को क्षणिक सॉफ्टवेयर विकास के रूप में अस्पष्ट रूप से वर्णित किया जा सकता है। अन्य पद्धतियों में [[झरना मॉडल|जलप्रपात]], [[सॉफ्टवेयर प्रोटोटाइप|सॉफ्टवेयर प्रोटोटाइपिंग]], [[पुनरावृत्त और वृद्धिशील विकास|पुनरावृत्त एवं वृद्धिशील विकास]], [[सर्पिल विकास]], तीव्र अनुप्रयोग विकास एवं [[चरम कार्यक्रम|अंतिम कार्यक्रम]] सम्मिलित हैं। जीवन-चक्र मॉडल को कभी-कभी कार्यप्रणालियों की श्रेणी के लिए अधिक सामान्य शब्द माना जाता है एवं विशिष्ट संगठन द्वारा चयनित की गई विशिष्ट प्रक्रिया को संदर्भित करने के लिए सॉफ़्टवेयर विकास प्रक्रिया को अधिक विशिष्ट शब्द माना जाता है। उदाहरण के लिए, कई विशिष्ट सॉफ़्टवेयर विकास प्रक्रियाएँ हैं जो सर्पिल जीवन-चक्र मॉडल में उपयुक्त होती हैं। क्षेत्र को प्रायः [[सिस्टम विकास जीवन चक्र|प्रणाली विकास जीवन चक्र]] का उपसमुच्चय माना जाता है।


== इतिहास ==
== इतिहास ==


सॉफ्टवेयर विकास मेथडोलॉजी (जिसे SDM के रूप में भी जाना जाता है) फ्रेमवर्क [[1960 के दशक]] तक सामने नहीं आया था। इलियट (2004) के अनुसार, प्रणाली विकास जीवन चक्र (SDLC) को [[सूचना प्रणाली]] के निर्माण के लिए अत्यधिक प्राचीन औपचारिक कार्यप्रणाली आकृति मानी जा सकती है। एसडीएलसी का मुख्य विचार सूचना प्रणाली के विकास को अत्यधिक सुविचारित, संरचित एवं व्यवस्थित उपाये से आगे बढ़ाने के लिए किया गया है, जिसमें जीवन चक्र के प्रत्येक चरण की आवश्यकता होती है-विचार के प्रारम्भ से लेकर अंतिम प्रणाली की डिलीवरी तक-होने के लिए सख्ती से एवं क्रमिक रूप से किया गया I<ref name="Ell04">Geoffrey Elliott (2004) ''Global Business Information Technology: an integrated systems approach''. Pearson Education. p.87.</ref> लागू किए जा रहे आकृति के संदर्भ में 1960 के दशक में इस कार्यप्रणाली आकृति का मुख्य लक्ष्य बड़े स्तर के व्यापारिक समूहों के युग में बड़े स्तर पर कार्यात्मक [[व्यापार प्रणाली]] विकसित करना था। सूचना प्रणाली की गतिविधियाँ भारी [[डाटा प्रासेसिंग]] एवं [[हिसाब लगाना|अभिकलन]] रूटीन के चारों ओर पर्यटन करती हैं।<ref name=Ell04/>
सॉफ्टवेयर विकास मेथडोलॉजी (जिसे SDM के रूप में भी जाना जाता है) फ्रेमवर्क [[1960 के दशक]] तक सामने नहीं आया था। इलियट (2004) के अनुसार, प्रणाली विकास जीवन चक्र (SDLC) को [[सूचना प्रणाली]] के निर्माण के लिए अत्यधिक प्राचीन औपचारिक कार्यप्रणाली आकृति मानी जा सकती है। एसडीएलसी का मुख्य विचार सूचना प्रणाली के विकास को अत्यधिक सुविचारित, संरचित एवं व्यवस्थित उपाये से आगे बढ़ाने के लिए किया गया है, जिसमें जीवन चक्र के प्रत्येक चरण की आवश्यकता होती है, विचार के प्रारम्भ से लेकर अंतिम प्रणाली की डिलीवरी तक होने के लिए जटिलता से एवं क्रमिक रूप से किया गया I<ref name="Ell04">Geoffrey Elliott (2004) ''Global Business Information Technology: an integrated systems approach''. Pearson Education. p.87.</ref> प्रारम्भ किए जा रहे आकृति के संदर्भ में 1960 के दशक में इस कार्य प्रणाली आकृति का मुख्य लक्ष्य बड़े स्तर के व्यापारिक समूहों के युग में बड़े स्तर पर कार्यात्मक [[व्यापार प्रणाली]] विकसित करना था। सूचना प्रणाली की गतिविधियाँ भारी [[डाटा प्रासेसिंग]] एवं [[हिसाब लगाना|अभिकलन]] दिनचर्या के चारों ओर पर्यटन करती हैं।<ref name=Ell04/>


कार्यप्रणालियाँ, प्रक्रियाएँ, एवं आकृति विशिष्ट निर्देशात्मक पदों से लेकर होते हैं जिनका उपयोग किसी संगठन द्वारा दिन-प्रतिदिन के कार्य में किया जा सकता है,परिवर्तनशील आकृति के लिए जिसका उपयोग संगठन किसी विशिष्ट परियोजना की आवश्यकताओं के अनुरूप पदों के प्रचलन समूह को उत्पन्न करने के लिए करता है या समूह कुछ स्तिथियों में, प्रायोजक या रखरखाव संगठन प्रपत्र का आधिकारिक समूह वितरित करता है जो प्रक्रिया का वर्णन करता है। विशिष्ट उदाहरणों में सम्मिलित हैं:
कार्यप्रणालियाँ, प्रक्रियाएँ, एवं आकृति विशिष्ट निर्देशात्मक पदों से लिए जाते हैं जिनका उपयोग किसी संगठन द्वारा दिन-प्रतिदिन के कार्य में किया जा सकता है,परिवर्तनशील आकृति के लिए जिसका उपयोग संगठन किसी विशिष्ट परियोजना की आवश्यकताओं के अनुरूप पदों के प्रचलन समूह को उत्पन्न करने के लिए करता है या समूह कुछ स्तिथियों में, प्रायोजक या सुरक्षा संगठन प्रपत्र का आधिकारिक समूह वितरित करता है जो प्रक्रिया का वर्णन करता है। विशिष्ट उदाहरणों में सम्मिलित हैं:


; [[1970 के दशक]]
; [[1970 के दशक]]
* 1969 से [[संरचित प्रोग्रामिंग]]
* 1969 से [[संरचित प्रोग्रामिंग]]
* [[Cap Gemini SDM|कैप जेमिनी एसडीएम (Cap Gemini SDM)]], मूल रूप से पांडाता (PANDATA) से, प्रथम अंग्रेजी अनुवाद 1974 में प्रकाशित हुआ था। एसएडीएम (SDM) का अर्थ प्रणाली विकास मेथडोलॉजी है
* [[Cap Gemini SDM|कैप जेमिनी एसडीएम (Cap Gemini SDM)]], मूल रूप से पांडाता (PANDATA) से, प्रथम अंग्रेजी अनुवाद 1974 में प्रकाशित हुआ था। एसएडीएम (SDM) का अर्थ प्रणाली विकास मेथडोलॉजी हैI
; [[1980 के दशक]]
; [[1980 के दशक]]
* 1980 के पश्चात से संरचित प्रणाली विश्लेषण एवं डिजाइन पद्धति (एसएसएडीएम)।
* 1980 के पश्चात से संरचित प्रणाली विश्लेषण एवं डिजाइन पद्धति (एसएसएडीएम) है।
* सूचना आवश्यकता विश्लेषण / सॉफ्ट प्रणाली पद्धति
* सूचना आवश्यकता विश्लेषण / सॉफ्ट प्रणाली पद्धति है।
; [[1990 के दशक]]
; [[1990 के दशक]]
* वस्तु-उन्मुख प्रोग्रामिंग (OOP) 1960 के दशक के प्रारम्भ में विकसित हुई एवं 1990 के दशक के मध्य में प्रमुख प्रोग्रामिंग दृष्टिकोण बन गई।
* वस्तु-उन्मुख प्रोग्रामिंग (OOP) 1960 के दशक के प्रारम्भ में विकसित हुई एवं 1990 के दशक के मध्य में प्रमुख प्रोग्रामिंग दृष्टिकोण बन गई।
Line 36: Line 35:
* [[DevOps|देवोपस (DevOps)]]
* [[DevOps|देवोपस (DevOps)]]


यह उल्लेखनीय है कि 1994 में डीएसडीएम (DSDM) के पश्चात से, RUP को त्यागकर उपरोक्त सूची की सभी कार्यप्रणालियाँ निपुण रही हैं - फिर भी कई संगठन, विशेष रूप से सरकारें, अभी भी प्री-एजाइल प्रक्रियाओं (प्रायःजलप्रपात या समान) का उपयोग करती हैं। सॉफ़्टवेयर प्रक्रिया एवं सॉफ़्टवेयर गुणवत्ता का परस्पर गहन संबंध है; व्यवहार में कुछ अनपेक्षित पहलू एवं प्रभाव देखे गए हैं  <ref name="ieeesw">{{Cite journal | doi =  10.1109/MS.2015.87 | title = Software Process versus Design Quality: Tug of War? | journal = IEEE Software | volume = 32 | issue = 4 | pages = 7–11 | year = 2015 | last1 = Suryanarayana | first1 = Girish }}</ref> इनमें से अन्य सॉफ्टवेयर विकास प्रोसेस [[खुला स्रोत सॉफ्टवेयर]] में स्थापित किया गया है। किसी कंपनी की सीमाओं के अंदर ज्ञात एवं स्थापित प्रक्रियाओं के इन सर्वोत्तम अभ्यासों को अपनाने को [[आंतरिक स्रोत]] कहा जाता है।
यह उल्लेखनीय है कि 1994 में डीएसडीएम (DSDM) के पश्चात से, आरयूपी (RUP) को त्यागकर उपरोक्त सूची की सभी कार्यप्रणालियाँ निपुण रही हैं, फिर भी कई संगठन, विशेष रूप से सरकारें, अभी भी प्री-एजाइल प्रक्रियाओं (प्रायःजलप्रपात या समान) का उपयोग करती हैं। सॉफ़्टवेयर प्रक्रिया एवं सॉफ़्टवेयर गुणवत्ता का परस्पर गहन संबंध है; व्यवहार में कुछ अनपेक्षित सापेक्ष एवं प्रभाव देखे गए हैं  <ref name="ieeesw">{{Cite journal | doi =  10.1109/MS.2015.87 | title = Software Process versus Design Quality: Tug of War? | journal = IEEE Software | volume = 32 | issue = 4 | pages = 7–11 | year = 2015 | last1 = Suryanarayana | first1 = Girish }}</ref> इनमें से अन्य सॉफ्टवेयर विकास प्रोसेस [[खुला स्रोत सॉफ्टवेयर|ओपन स्रोत सॉफ्टवेयर]] में स्थापित किया गया है। किसी कंपनी की सीमाओं के अंदर ज्ञात एवं स्थापित प्रक्रियाओं के इन सर्वोत्तम अभ्यासों को अपनाने को [[आंतरिक स्रोत]] कहा जाता है।


== प्रोटोटाइपिंग ==
== प्रोटोटाइपिंग ==
Line 42: Line 41:
सॉफ़्टवेयर प्रोटोटाइपिंग प्रोटोटाइप बनाने के विषय में है, अर्थात विकसित किए जा रहे सॉफ़्टवेयर प्रोग्राम के अर्द्धनिर्मित संस्करण मूल सिद्धांत हैं:<ref name="CMS08" />
सॉफ़्टवेयर प्रोटोटाइपिंग प्रोटोटाइप बनाने के विषय में है, अर्थात विकसित किए जा रहे सॉफ़्टवेयर प्रोग्राम के अर्द्धनिर्मित संस्करण मूल सिद्धांत हैं:<ref name="CMS08" />


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


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


== उपाये ==
== उपाये ==


=== प्रवीण विकास ===
=== प्रवीण विकास ===
{{main|चुस्त सॉफ्टवेयर विकास}}
{{main|प्रवीण सॉफ्टवेयर विकास}}


प्रवीण सॉफ्टवेयर विकास पुनरावृत्त विकास के आधार पर सॉफ्टवेयर विकास आकृति के समूह को संदर्भित करता है, जहां स्व-संगठित क्रॉस-फंक्शनल समूहों के मध्य सहयोग के माध्यम से आवश्यकताएं एवं समाधान विकसित होते हैं। यह शब्द वर्ष 2001 में बनाया गया था जब [[द एजाइल मेनिफेस्टो]] प्रस्तुत किया गया था।
प्रवीण सॉफ्टवेयर विकास पुनरावृत्त विकास के आधार पर सॉफ्टवेयर विकास आकृति के समूह को संदर्भित करता है, जहां स्व-संगठित क्रॉस-फंक्शनल समूहों के मध्य सहयोग के माध्यम से आवश्यकताएं एवं समाधान विकसित होते हैं। यह शब्द वर्ष 2001 में बनाया गया था जब [[द एजाइल मेनिफेस्टो]] प्रस्तुत किया गया था।
Line 69: Line 68:
{{main|निरंतर एकीकरण}}
{{main|निरंतर एकीकरण}}


निरंतर एकीकरण सभी डेवलपर कार्यशील प्रतियों को ट्रंक (सॉफ़्टवेयर) में दिन में कई बार व्याधि करने का अभ्यास है।<ref name="CI0">{{Cite web|url=https://www.thoughtworks.com/continuous-integration|title=Continuous Integration}}</ref> [[ग्रेडी बूच]] ने प्रथम बार [[बूच विधि]] में सीआई का नाम दिया एवं प्रस्तावित किया,<ref>{{cite book |last= Booch |first= Grady |author-link= Grady Booch |year= 1991 |title=Object Oriented Design: With Applications |url= https://books.google.com/books?id=w5VQAAAAMAAJ&q=continuous+integration+inauthor:grady+inauthor:booch |publisher= [[Benjamin Cummings]] |page= 209 |isbn= 9780805300918 |access-date= 18 August 2014 }}</ref> चूँकि उन्होंने दिन में कई बार एकीकरण करने का प्रतिनिधित्व नहीं किया। एक्सट्रीम प्रोग्रामिंग (XP) ने CI की अवधारणा को अपनाया एवं प्रतिदिन एकीकृत करने का प्रतिनिधित्व I
निरंतर एकीकरण सभी डेवलपर कार्यशील प्रतियों को ट्रंक (सॉफ़्टवेयर) में दिन में कई बार व्याधि करने का अभ्यास है।<ref name="CI0">{{Cite web|url=https://www.thoughtworks.com/continuous-integration|title=Continuous Integration}}</ref> [[ग्रेडी बूच]] ने प्रथम बार [[बूच विधि]] में सीआई का नाम दिया एवं प्रस्तावित किया,<ref>{{cite book |last= Booch |first= Grady |author-link= Grady Booch |year= 1991 |title=Object Oriented Design: With Applications |url= https://books.google.com/books?id=w5VQAAAAMAAJ&q=continuous+integration+inauthor:grady+inauthor:booch |publisher= [[Benjamin Cummings]] |page= 209 |isbn= 9780805300918 |access-date= 18 August 2014 }}</ref> चूँकि उन्होंने दिन में कई बार एकीकरण करने का प्रतिनिधित्व नहीं किया। एक्सट्रीम प्रोग्रामिंग (XP) ने सीआई (CI) की अवधारणा को अपनाया एवं प्रतिदिन एकीकृत करने का प्रतिनिधित्व किया I


=== वृद्धिशील विकास ===
=== वृद्धिशील विकास ===
{{main|पुनरावृत्त एवं वृद्धिशील विकास}}
{{main|पुनरावृत्त एवं वृद्धिशील विकास}}


रैखिक एवं पुनरावृत्त प्रणालियों के विकास के उपाये के संयोजन के लिए विभिन्न उपाये स्वीकार्य हैं, जिनमें से प्रत्येक का प्राथमिक उद्देश्य  परियोजना को छोटे खंडों में तोड़कर निहित परियोजना विपत्ति को अर्घ्य करना एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करना है।
रैखिक एवं पुनरावृत्त प्रणालियों के विकास के उपाये के संयोजन के लिए विभिन्न उपाये स्वीकार्य किये हैं, जिनमें से प्रत्येक का प्राथमिक उद्देश्य  परियोजना को छोटे खंडों में विभक्त करके निहित परियोजना विपत्ति को अर्घ्य करना एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करना है।


वृद्धिशील विकास के तीन मुख्य रूप हैं:<ref name=CMS08/>
वृद्धिशील विकास के तीन मुख्य रूप हैं:<ref name=CMS08/>


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


Line 85: Line 84:
{{main|रैपिड अनुप्रयोग का विकास}}
{{main|रैपिड अनुप्रयोग का विकास}}


[[File:RADModel.JPG|thumb|रैपिड एप्लीकेशन विकास (आरएडी) मॉडल]]रैपिड अनुप्रयोग विकास (आरएडी) सॉफ्टवेयर विकास मेथडोलॉजी है, जो बड़ी मात्रा में अप-फ्रंट प्लानिंग के अतिरिक्त पुनरावृत्त विकास एवं  [[प्रोटोटाइप]] के तीव्र गति से निर्माण का पक्षधर है। आरएडी का उपयोग कर विकसित सॉफ्टवेयर की योजना स्वयं सॉफ्टवेयर लिखने के साथ जुड़ी हुई है। व्यापक पूर्व-योजना की कमी सामान्यतः सॉफ़्टवेयर को अत्यधिक तीव्र गति से लिखने की अनुमति देती है, एवं आवश्यकताओं को परिवर्तित करने में सरल बनाती है।
[[File:RADModel.JPG|thumb|तीव्र आवेदन विकास (आरएडी) मॉडल]]रैपिड अनुप्रयोग विकास (आरएडी) सॉफ्टवेयर विकास मेथडोलॉजी है, जो बड़ी मात्रा में अप-फ्रंट प्लानिंग के अतिरिक्त पुनरावृत्त विकास एवं  [[प्रोटोटाइप]] के तीव्र गति से निर्माण का पक्षधर है। आरएडी का उपयोग कर विकसित सॉफ्टवेयर की योजना स्वयं सॉफ्टवेयर लिखने के साथ जुड़ी हुई है। व्यापक पूर्व-योजना की कमी सामान्यतः सॉफ़्टवेयर को अत्यधिक तीव्र गति से लिखने की अनुमति देती है, एवं आवश्यकताओं को परिवर्तित करने में सरल बनाती है।


तीव्र विकास प्रक्रिया [[संरचित तकनीक|संरचित प्रौद्योगिकी]] का उपयोग करके प्रारंभिक [[डेटा मॉडल]] एवं व्यवसाय प्रक्रिया मॉडल के विकास के साथ प्रारम्भ होती है। अगले चरण में, प्रोटोटाइप का उपयोग करके आवश्यकताओं को सत्यापित किया जाता है, अंततः डेटा एवं प्रक्रिया मॉडल को परिष्कृत करने के लिए, इन चरणों को पुनरावृत्त रूप से दोहराया जाता है; नई प्रणालियों के निर्माण के लिए उपयोग की जाने वाली संयुक्त व्यावसायिक आवश्यकताओं एवं प्रौद्योगिकी डिजाइन विवरण में आगे के विकास के परिणाम है।<ref name=WBD04/>
तीव्र विकास प्रक्रिया [[संरचित तकनीक|संरचित प्रौद्योगिकी]] का उपयोग करके प्रारंभिक [[डेटा मॉडल]] एवं व्यवसाय प्रक्रिया मॉडल के विकास के साथ प्रारम्भ होती है। अगले चरण में, प्रोटोटाइप का उपयोग करके आवश्यकताओं को सत्यापित किया जाता है, अंततः डेटा एवं प्रक्रिया मॉडल को परिष्कृत करने के लिए, इन चरणों को पुनरावृत्त रूप से दोहराया जाता है; नई प्रणालियों के निर्माण के लिए उपयोग की जाने वाली संयुक्त व्यावसायिक आवश्यकताओं एवं प्रौद्योगिकी डिजाइन विवरण में आगे के विकास के परिणाम है।<ref name=WBD04/>
Line 92: Line 91:


* मुख्य उद्देश्य अपेक्षाकृत कम निवेश वित्त पर उच्च गुणवत्ता वाली प्रणाली का तीव्र गति से विकास एवं वितरण करना है।
* मुख्य उद्देश्य अपेक्षाकृत कम निवेश वित्त पर उच्च गुणवत्ता वाली प्रणाली का तीव्र गति से विकास एवं वितरण करना है।
* परियोजना को छोटे खंडों में करके एवं  विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके निहित परियोजना विपत्ति को अल्प करने का प्रयास।
* परियोजना को छोटे खंडों में करके एवं  विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके निहित परियोजना विपत्ति को अल्प करने का प्रयास हैं।
* मुख्य रूप से पुनरावृत्त प्रोटोटाइप (विकास के किसी भी चरण में), सक्रिय उपयोगकर्ता भागीदारी एवं कम्प्यूटरीकृत विकास उपकरण के माध्यम से उच्च गुणवत्ता वाली प्रणालियों का निर्माण करना है। इन उपकरणों में [[ग्राफिकल यूज़र इंटरफ़ेस]] (GUI) बिल्डर्स, [[कंप्यूटर एडेड सॉफ्टवेयर इंजीनियरिंग]] (CASE) टूल्स, [[डेटाबेस प्रबंधन प्रणाली]] (DBMS), [[चौथी पीढ़ी की प्रोग्रामिंग भाषा]], कोड जनरेटर एवं ऑब्जेक्ट-ओरिएंटेड प्रविधि सम्मिलित हो सकती हैं।
* मुख्य रूप से पुनरावृत्त प्रोटोटाइप (विकास के किसी भी चरण में), सक्रिय उपयोगकर्ता भागीदारी एवं कम्प्यूटरीकृत विकास उपकरण के माध्यम से उच्च गुणवत्ता वाली प्रणालियों का निर्माण करना है। इन उपकरणों में [[ग्राफिकल यूज़र इंटरफ़ेस]] (GUI) निर्माता, [[कंप्यूटर एडेड सॉफ्टवेयर इंजीनियरिंग]] (CASE) टूल्स, [[डेटाबेस प्रबंधन प्रणाली]] (DBMS), [[चौथी पीढ़ी की प्रोग्रामिंग भाषा]], कोड जनरेटर एवं ऑब्जेक्ट-ओरिएंटेड प्रविधि सम्मिलित हो सकती हैं।
* व्यवसाय की आवश्यकता को पूर्ण करने पर मुख्य बल दिया जाता है, जबकि प्रौद्योगिकी या इंजीनियरिंग उत्कृष्टता का महत्व अल्प होता है।
* व्यवसाय की आवश्यकता को पूर्ण करने पर मुख्य बल दिया जाता है, जबकि प्रौद्योगिकी या इंजीनियरिंग उत्कृष्टता का महत्व अल्प होता है।
* परियोजना नियंत्रण में विकास को प्राथमिकता देना एवं डिलीवरी की समय सीमा या "टाइमबॉक्स" को परिभाषित करना सम्मिलित  है। यदि परियोजना विफल होने लगती है, तो समय-सीमा में उपयुक्त होने के लिए आवश्यकताओं को अल्प करने पर बल दिया जाता है, न कि समय सीमा बढ़ाने में।
* परियोजना नियंत्रण में विकास को प्राथमिकता देना एवं डिलीवरी की समय सीमा या "टाइमबॉक्स" को परिभाषित करना सम्मिलित  है। यदि परियोजना विफल होने लगती है, तो समय-सीमा में उपयुक्त होने के लिए आवश्यकताओं को अल्प करने पर बल दिया जाता है, न कि समय सीमा बढ़ाने में बल देता है।
* सामान्यतः संयुक्त अनुप्रयोग डिज़ाइन (JAD) सम्मिलित होता है, जहाँ उपयोगकर्ता या तो संरचित कार्यशालाओं में सर्वसम्मति निर्माण के माध्यम से, या इलेक्ट्रॉनिक रूप से वार्तालाप के माध्यम से [[प्रणाली की रूपरेखा]] में गंभीर रूप से सम्मिलित  होते हैं।
* सामान्यतः संयुक्त अनुप्रयोग डिज़ाइन (JAD) सम्मिलित होता है, जहाँ उपयोगकर्ता या तो संरचित कार्यशालाओं में सर्वसम्मति निर्माण के माध्यम से, या इलेक्ट्रॉनिक रूप से वार्तालाप के माध्यम से [[प्रणाली की रूपरेखा]] में गंभीर रूप से सम्मिलित  होते हैं।
* सक्रिय उपयोगकर्ता भागीदारी अनिवार्य है।
* सक्रिय उपयोगकर्ता भागीदारी अनिवार्य है।
* फेंकने वाले प्रोटोटाइप के विपरीत, क्रमिक रूप से उत्पादन सॉफ्टवेयर का उत्पादन करता है।
* प्रोटोटाइप के विपरीत, क्रमिक रूप से उत्पादन सॉफ्टवेयर का उत्पादन करता है।
* भविष्य के विकास एवं रखरखाव की सुविधा के लिए आवश्यक प्रपत्र प्रस्तुत करता है।
* भविष्य के विकास एवं सुरक्षा की सुविधा के लिए आवश्यक प्रपत्र प्रस्तुत करता है।
* इस आकृति में मानक प्रणाली विश्लेषण एवं डिजाइन विधियों को उपयुक्त किया जा सकता है।
* इस आकृति में मानक प्रणाली विश्लेषण एवं डिजाइन विधियों को उपयुक्त किया जा सकता है।


=== झरना विकास ===
=== जलप्रपात विकास ===
{{main|झरना मॉडल}}
{{main|जलप्रपात मॉडल}}


[[File:Waterfall model.svg|thumb|वाटरफॉल मॉडल में प्रदर्शित सॉफ्टवेयर विकास प्रक्रिया की गतिविधियां। इस प्रक्रिया का प्रतिनिधित्व करने के लिए कई अन्य मॉडल हैं।]]जलप्रपात मॉडल क्रमिक विकास दृष्टिकोण है, जिसमें विकास को कई चरणों के माध्यम से निरंतर नीचे की ओर सामान्यतः (झरने के जैसे) बहने के रूप में देखा जाता हैI
[[File:Waterfall model.svg|thumb|वाटरफॉल मॉडल में प्रदर्शित सॉफ्टवेयर विकास प्रक्रिया की गतिविधियां। इस प्रक्रिया का प्रतिनिधित्व करने के लिए कई अन्य मॉडल हैं।]]जलप्रपात मॉडल क्रमिक विकास का दृष्टिकोण है, जिसमें विकास को कई चरणों के माध्यम से निरंतर नीचे की ओर सामान्यतः (जलप्रपात के जैसे) बहने के रूप में देखा जाता हैI


* आवश्यकताओं का विश्लेषण जिसके परिणामस्वरूप एक सॉफ्टवेयर आवश्यकता विनिर्देशन होता है
* आवश्यकताओं का विश्लेषण जिसके परिणामस्वरूप एक सॉफ्टवेयर आवश्यकता विनिर्देशन होता है
Line 115: Line 114:
* [[सॉफ्टवेयर की रखरखाव|सॉफ्टवेयर रखरखाव]]
* [[सॉफ्टवेयर की रखरखाव|सॉफ्टवेयर रखरखाव]]


विधि का प्रथम औपचारिक विवरण प्रायः विंस्टन डब्ल्यू रॉयस द्वारा प्रकाशित लेख के रूप में उद्धृत किया जाता है<ref>[http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html Wasserfallmodell > Entstehungskontext], Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.</ref> 1970 में,चूँकि रॉयस ने इस लेख में जलप्रपात शब्द का प्रयोग नहीं किया। रॉयस ने इस मॉडल को त्रुटिपूर्ण, अन्य-कार्यशील मॉडल के उदाहरण के रूप में प्रस्तुत किया।<ref>Conrad Weisert, [http://www.idinews.com/waterfall.html Waterfall methodology: there's no such thing!]</ref> मूल सिद्धांत हैं:<ref name=CMS08/>
विधि का प्रथम औपचारिक विवरण प्रायः विंस्टन डब्ल्यू रॉयस द्वारा प्रकाशित लेख के रूप में उद्धृत किया जाता हैI<ref>[http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html Wasserfallmodell > Entstehungskontext], Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.</ref> 1970 में, चूँकि रॉयस ने इस लेख में जलप्रपात शब्द का प्रयोग नहीं किया। रॉयस ने इस मॉडल को त्रुटिपूर्ण, अन्य-कार्यशील मॉडल के उदाहरण के रूप में प्रस्तुत किया।<ref>Conrad Weisert, [http://www.idinews.com/waterfall.html Waterfall methodology: there's no such thing!]</ref> मूल सिद्धांत हैं:<ref name=CMS08/>


* परियोजना को अनुक्रमिक चरणों में विभाजित किया गया है, कुछ चरणों के मध्य कुछ ओवरलैप एवं स्प्लैश बैक स्वीकार्य हैं।
* परियोजना को अनुक्रमिक चरणों में विभाजित किया गया है, कुछ चरणों के मध्य कुछ ओवरलैप एवं स्प्लैश बैक स्वीकार्य हैं।
Line 121: Line 120:
* अगले चरण की प्रारम्भ से पूर्व अधिकांश चरणों के अंत में होने वाले उपयोगकर्ता एवं  [[सूचना प्रौद्योगिकी प्रबंधन]] द्वारा व्यापक लिखित प्रपत्रीकरण, औपचारिक समीक्षा, एवं अनुमोदन के माध्यम से परियोजना के जीवन पर कठिन नियंत्रण बनाए रखा जाता है। लिखित प्रपत्र प्रत्येक चरण का स्पष्ट अनुकूलन है।
* अगले चरण की प्रारम्भ से पूर्व अधिकांश चरणों के अंत में होने वाले उपयोगकर्ता एवं  [[सूचना प्रौद्योगिकी प्रबंधन]] द्वारा व्यापक लिखित प्रपत्रीकरण, औपचारिक समीक्षा, एवं अनुमोदन के माध्यम से परियोजना के जीवन पर कठिन नियंत्रण बनाए रखा जाता है। लिखित प्रपत्र प्रत्येक चरण का स्पष्ट अनुकूलन है।


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


=== सर्पिल विकास ===
=== सर्पिल विकास ===
Line 129: Line 128:
{{main|
{{main|
सर्पिल मॉडल}}
सर्पिल मॉडल}}
1988 में, [[बैरी बोहेम]] ने औपचारिक सॉफ्टवेयर प्रणाली विकास स्पाइरल मॉडल प्रकाशित किया, जो [[टॉप-डाउन और बॉटम-अप डिज़ाइन|टॉप-डाउन एवं बॉटम-अप डिज़ाइन]]  टॉप-डाउन एवं बॉटम के लाभों को मिलाने के प्रयास में वॉटरफॉल मॉडल एवं रैपिड अनुप्रयोग विकास मेथडोलॉजी के कुछ प्रमुख विषयो को जोड़ता है। इसने प्रमुख क्षेत्र पर बल दिया, जिसे कई लोगों ने अनुभव किया कि अन्य पद्धतियों द्वारा उपेक्षित किया गया था: विचारपूर्वक पुनरावृत्त विपत्ति विश्लेषण, विशेष रूप से बड़े स्तर पर कठिन प्रणालियों के अनुकूल मूल सिद्धांत हैं:<ref name="CMS08" />
1988 में, [[बैरी बोहेम]] ने औपचारिक सॉफ्टवेयर प्रणाली विकास स्पाइरल मॉडल प्रकाशित किया, जो [[टॉप-डाउन और बॉटम-अप डिज़ाइन|टॉप-डाउन एवं बॉटम-अप डिज़ाइन]]  के लाभों को मिलाने के प्रयास में वॉटरफॉल मॉडल एवं रैपिड अनुप्रयोग विकास मेथडोलॉजी के कुछ प्रमुख विषयो को जोड़ता है। इसने प्रमुख क्षेत्र पर बल दिया, जिसे कई लोगों ने अनुभव किया कि अन्य पद्धतियों द्वारा उपेक्षित किया गया था: विचारपूर्वक पुनरावृत्त विपत्ति विश्लेषण, विशेष रूप से बड़े स्तर पर कठिन प्रणालियों के अनुकूल मूल सिद्धांत हैं:<ref name="CMS08" />


* केन्द्रित विपत्ति मूल्यांकन पर है एवं परियोजना को छोटे खंडों में करके एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके परियोजना विपत्ति को अल्प करने के साथ-साथ विपत्ति का मूल्यांकन करने एवं सम्पूर्ण जीवन चक्र में परियोजना की निरंतरता पर विचार करने का अवसर प्रदान करता है। .
* केन्द्रित विपत्ति मूल्यांकन पर है एवं परियोजना को छोटे खंडों में करके एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके परियोजना विपत्ति को अल्प करने के साथ-साथ विपत्ति का मूल्यांकन करने एवं सम्पूर्ण जीवन चक्र में परियोजना की निरंतरता पर विचार करने का सुयोग प्रदान करता है। .
* प्रत्येक चक्र में उत्पाद के प्रत्येक भाग के लिए एवं विस्तार के प्रत्येक स्तर के लिए चरणों के क्रम के माध्यम से प्रगति सम्मिलित  है, समग्र अवधारणा-संचालन प्रपत्रो से लेकर प्रत्येक व्यक्तिगत कार्यक्रम की कोडिंग तक।<ref name="BB86">[[Barry Boehm]] (1996)., [http://doi.acm.org/10.1145/12944.12948 "A Spiral Model of Software Development and Enhancement]". In: ''ACM SIGSOFT Software Engineering Notes'' (ACM) 11(4):14-24, August 1986</ref>
* प्रत्येक चक्र में उत्पाद के प्रत्येक भाग के लिए एवं विस्तार के प्रत्येक स्तर के लिए चरणों के क्रम के माध्यम से प्रगति सम्मिलित  है, समग्र अवधारणा-संचालन प्रपत्रो से लेकर प्रत्येक व्यक्तिगत कार्यक्रम की कोडिंग तक है।<ref name="BB86">[[Barry Boehm]] (1996)., [http://doi.acm.org/10.1145/12944.12948 "A Spiral Model of Software Development and Enhancement]". In: ''ACM SIGSOFT Software Engineering Notes'' (ACM) 11(4):14-24, August 1986</ref>
* सर्पिल के चारों ओर प्रत्येक यात्रा चार मूल चतुर्भुजों को पार करती है: (1) पुनरावृत्ति के उद्देश्यों, विकल्पों एवं बाधाओं को निर्धारित करती है, एवं (2) विकल्पों का मूल्यांकन करती है; विपत्तियो की पहचानें एवं निवारण करें; (3) पुनरावृत्ति से डिलिवरेबल्स का विकास एवं सत्यापन; एवं (4) अगले पुनरावृत्ति की योजना बनाएं।<ref name="RT-BB86">Richard H. Thayer, Barry W. Boehm (1986). ''Tutorial: software engineering project management''. Computer Society Press of the IEEE. p.130</ref>
* सर्पिल के चारों ओर प्रत्येक यात्रा चार मूल चतुर्भुजों को ज्ञात करती है: (1) पुनरावृत्ति के उद्देश्यों, विकल्पों एवं बाधाओं को निर्धारित करती है, एवं (2) विकल्पों का मूल्यांकन करती है; विपत्तियो की पहचानें एवं निवारण करें; (3) पुनरावृत्ति से डिलिवरेबल्स का विकास एवं सत्यापन; एवं (4) अगले पुनरावृत्ति की योजना बनाएं।<ref name="RT-BB86">Richard H. Thayer, Barry W. Boehm (1986). ''Tutorial: software engineering project management''. Computer Society Press of the IEEE. p.130</ref>
* प्रत्येक चक्र को हितधारकों एवं उनकी विजय की स्थिति की पहचान के साथ प्रारम्भ करें, एवं प्रत्येक चक्र को समीक्षा एवं प्रतिबद्धता के साथ समाप्त करें।<ref>Barry W. Boehm (2000). ''Software cost estimation with Cocomo II: Volume 1''.</ref>
* प्रत्येक चक्र को हितधारकों एवं उनकी विजय की स्थिति की पहचान के साथ प्रारम्भ करें, एवं प्रत्येक चक्र को समीक्षा एवं प्रतिबद्धता के साथ समाप्त करें।<ref>Barry W. Boehm (2000). ''Software cost estimation with Cocomo II: Volume 1''.</ref>




=== आकार ===
=== आकार ===
आकार 2018 में [[बेसकैंप (कंपनी)]] द्वारा प्रस्तुत किया गया, सॉफ्टवेयर विकास दृष्टिकोण है। यह सिद्धांतों एवं प्रौद्योगिकीयो का समहू है जिसे बेसकैंप ने आंतरिक रूप से विकसित किया है जिससे बिना किसी स्पष्ट अंत के परियोजनाओं की समस्या को दूर किया जा सके। इसका प्राथमिक लक्षित दर्शक दूरस्थ समहू हैं। वॉटरफॉल मॉडल, एजाइल सॉफ्टवेयर विकास या स्क्रम (सॉफ्टवेयर विकास) के विपरीत आकार का कोई अनुमान एवं वेग ट्रैकिंग, बैकलॉग या स्प्रिंट नहीं है। इसके अनुसार, उन अवधारणाओं को भूख, सट्टेबाजी एवं चक्रों से परिवर्तित कर दिया जाता है। 2022 तक, बेसकैंप के अतिरिक्त, आकार को अपनाने वाले उल्लेखनीय संगठनों में उपयोगकर्ता आवाज (UserVoice) एवं ब्लॉक (Block) सम्मिलित  हैं।<ref>{{Cite web |title=Foreword by Jason Fried {{!}} Shape Up |url=https://basecamp.com/shapeup/0.1-foreword |access-date=2022-09-11 |website=basecamp.com}}</ref><ref>{{Cite web |title=Is Shape Up just a nice theory? |url=https://www.curiouslab.io/blog/is-shape-up-just-a-nice-theory |access-date=2022-09-12 |website=Curious Lab |language=en-AU}}</ref>
आकार 2018 में [[बेसकैंप (कंपनी)]] द्वारा प्रस्तुत किया गया, सॉफ्टवेयर विकास का दृष्टिकोण है। यह सिद्धांतों एवं प्रौद्योगिकीयो का समहू है जिसे बेसकैंप ने आंतरिक रूप से विकसित किया है जिससे बिना किसी स्पष्ट अंत के परियोजनाओं की समस्या को दूर किया जा सके। इसका प्राथमिक लक्षित दर्शक दूरस्थ समहू हैं। वॉटरफॉल मॉडल, एजाइल सॉफ्टवेयर विकास या स्क्रम (सॉफ्टवेयर विकास) के विपरीत आकार का कोई अनुमान एवं वेग ट्रैकिंग, बैकलॉग या स्प्रिंट नहीं है। इसके अनुसार, उन अवधारणाओं को एपेटाइट, सट्टेबाजी एवं चक्रों से परिवर्तित कर दिया जाता है। 2022 तक, बेसकैंप के अतिरिक्त, आकार को अपनाने वाले उल्लेखनीय संगठनों में उपयोगकर्ता ध्वनि (UserVoice) एवं ब्लॉक (Block) सम्मिलित  हैं।<ref>{{Cite web |title=Foreword by Jason Fried {{!}} Shape Up |url=https://basecamp.com/shapeup/0.1-foreword |access-date=2022-09-11 |website=basecamp.com}}</ref><ref>{{Cite web |title=Is Shape Up just a nice theory? |url=https://www.curiouslab.io/blog/is-shape-up-just-a-nice-theory |access-date=2022-09-12 |website=Curious Lab |language=en-AU}}</ref>




==== चक्र ====
==== चक्र ====
परीक्षणों एवं त्रुटियों के माध्यम से, बेसकैंप ने पाया कि आदर्श चक्र की अवधि 6 सप्ताह है। यह 6 सप्ताह की अवधि सार्थक विशेषता बनाने के लिए अत्यधिक बड़ी है एवं अत्यावश्यकता की भावना उत्पन्न करने के लिए अभी भी अत्यधिक अल्प है।
परीक्षणों एवं त्रुटियों के माध्यम से, बेसकैंप ने ज्ञात किया  कि आदर्श चक्र की अवधि 6 सप्ताह है। यह 6 सप्ताह की अवधि सार्थक विशेषता बनाने के लिए अत्यधिक बड़ी है एवं अत्यावश्यकता की भावना उत्पन्न करने के लिए अभी भी अत्यधिक अल्प है।


==== आकार देना ====
==== आकार देना ====
आकृति [[उपयोगकर्ता अनुभव डिजाइन]] एवं सॉफ्टवेयर इंजीनियरिंग को दिए जाने से पूर्व कार्य प्रस्तुत करने की प्रक्रिया है। आकार का कार्य समाधान के मुख्य UI तत्वों को बताता है, रैबिट होल की पहचान करता है, एवं कक्षा की स्पष्ट सीमाओं को रेखांकित करता है। इसका अर्थ रफ होना है एवं बिल्डरों (डिजाइनरों एवं  इंजीनियरों) को निवारण करने के लिए उत्तम विवरण त्यागना है, जिससे बिल्डर्स अपनी रचनात्मकता का प्रयोग कर सकें एवं ट्रेड-ऑफ कर सकें।<ref>{{Cite web |title=Principles of Shaping {{!}} Shape Up |url=https://basecamp.com/shapeup/1.1-chapter-02#property-1-its-rough |access-date=2022-09-11 |website=basecamp.com}}</ref> आकार के कार्य को ऑनलाइन प्रपत्रो के समाधान का उपयोग करके पिच के रूप में प्रलेखित किया जाता है जो टिप्पणी का समर्थन करता है, समहू के सदस्यों को अतुल्यकालिक रूप से  प्रौद्योगिकी जानकारी का योगदान करने की अनुमति देता है। इस प्रकार की टिप्पणियां विलुप्त आश्चर्यों को प्रकाशित करने के लिए महत्वपूर्ण हैं जो परियोजना को रेखा से उतार सकती हैं। चक्र प्रारम्भ होने से पूर्व, हितधारक सट्टेबाजी की मेज रखते हैं, जहां पिचों की समीक्षा की जाती है। प्रत्येक पिच के लिए, या तो उस पर आक्षिक लगाने या उसे त्यागने का निर्णय लिया जाता है।<ref>{{Cite web |title=Bets, Not Backlogs {{!}} Shape Up |url=https://basecamp.com/shapeup/2.1-chapter-07#a-few-potential-bets |access-date=2022-09-11 |website=basecamp.com}}</ref>
आकृति [[उपयोगकर्ता अनुभव डिजाइन]] एवं सॉफ्टवेयर इंजीनियरिंग को दिए जाने से पूर्व कार्य प्रस्तुत करने की प्रक्रिया है। आकार का कार्य समाधान के मुख्य युआई (UI) तत्वों को ज्ञात करता है, रैबिट होल की पहचान करता है, एवं कक्षा की स्पष्ट सीमाओं को रेखांकित करता है। इसका अर्थ रफ होना है एवं निर्माताों (डिजाइनरों एवं  इंजीनियरों) को निवारण करने के लिए उत्तम विवरण त्यागना है, जिससे निर्माता अपनी रचनात्मकता का प्रयोग कर सकें एवं ट्रेड-ऑफ कर सकें।<ref>{{Cite web |title=Principles of Shaping {{!}} Shape Up |url=https://basecamp.com/shapeup/1.1-chapter-02#property-1-its-rough |access-date=2022-09-11 |website=basecamp.com}}</ref> आकार के कार्य को ऑनलाइन प्रपत्रो के समाधान का उपयोग करके पिच के रूप में प्रलेखित किया जाता है जो टिप्पणी का समर्थन करता है, समहू के सदस्यों को अतुल्यकालिक रूप से  प्रौद्योगिकी जानकारी का योगदान करने की अनुमति देता है। इस प्रकार की टिप्पणियां विलुप्त आश्चर्यों को प्रकाशित करने के लिए महत्वपूर्ण हैं जो परियोजना को रेखा से विस्थापित कर सकती हैं। चक्र प्रारम्भ होने से पूर्व, हितधारक, जहां पिचों की समीक्षा की जाती है। प्रत्येक पिच के लिए, या तो उस पर आक्षिक लगाने या उसे त्यागने का निर्णय लिया जाता है।<ref>{{Cite web |title=Bets, Not Backlogs {{!}} Shape Up |url=https://basecamp.com/shapeup/2.1-chapter-07#a-few-potential-bets |access-date=2022-09-11 |website=basecamp.com}}</ref>






==== भूख ====
==== एपेटाइट ====
जिस तरह से शेप अप यह निर्धारित करता है कि किसी परियोजना के लिए कितना समय आवंटित किया गया है, वह अन्य पद्धतियों के बिल्कुल विपरीत है। शेप अप एक भूख के साथ प्रारम्भ होता है (उदाहरण के लिए, 6 सप्ताह) एवं एक समाधान डिजाइन के साथ समाप्त होता है जिसे इस बाधा के भीतर वितरित किया जा सकता है। परियोजना के बिल्डरों के लिए भूख एक कठिन समय सीमा बन जाती है।<ref>{{Cite web |title=Hand Over Responsibility {{!}} Shape Up |url=https://basecamp.com/shapeup/3.1-chapter-10#done-means-deployed |access-date=2022-09-11 |website=basecamp.com}}</ref>
जिस प्रकार से आकार यह निर्धारित करता है कि किसी परियोजना के लिए कितना समय आवंटित किया गया है, वह अन्य पद्धतियों के विपरीत है। आकार एपेटाइट के साथ प्रारम्भ होता है (उदाहरण के लिए, 6 सप्ताह) एवं समाधान डिजाइन के साथ समाप्त होता है जिसे इस बाधा के अंदर वितरित किया जा सकता है। परियोजना के निर्माता के लिए एपेटाइट कठिन समय सीमा बन जाती है।<ref>{{Cite web |title=Hand Over Responsibility {{!}} Shape Up |url=https://basecamp.com/shapeup/3.1-chapter-10#done-means-deployed |access-date=2022-09-11 |website=basecamp.com}}</ref>




==== भवन ====
==== भवन ====
शेप अप एक दो-ट्रैक प्रणाली है जहां शेपर एवं बिल्डर समानांतर में कार्य करते हैं। वर्तमान चक्र में जो कार्य आकार ले रहा है, वह भविष्य के चक्र में निर्माण करने के लिए डिजाइनरों एवं इंजीनियरों को दिया जा सकता है।
आकार दो-ट्रैक प्रणाली है जहां आकृति एवं निर्माता समानांतर में कार्य करते हैं। वर्तमान चक्र में जो कार्य आकार ले रहा है, वह भविष्य के चक्र में निर्माण करने के लिए डिजाइनरों एवं इंजीनियरों को दिया जा सकता है।


इमारत के साथ आने वाली तकनीकी अनिश्चितताओं को पहचानते हुए, एक चार्ट का उपयोग करके प्रगति को ट्रैक किया जाता है जो पहाड़ी के रूपक को देखता है, जिसे उपयुक्त रूप से पहाड़ी चार्ट नाम दिया गया है। अपहिल चरण वह है जहां बिल्डर्स अभी भी अपने दृष्टिकोण पर कार्य कर रहे हैं, जबकि डाउनहिल वह है जहां अज्ञात को समाप्त कर दिया गया है। बिल्डर्स बेसकैंप या [[रुको (सॉफ्टवेयर)]] पर एक इंटरैक्टिव ऑनलाइन हिल चार्ट का उपयोग करके सक्रिय रूप से एवं एसिंक्रोनस रूप से स्व-रिपोर्ट प्रगति करते हैं, फोकस को अज्ञात या हल की गई समस्याओं पर ध्यान केंद्रित करते हैं या नहीं किया जाता है। हिल चार्ट का उपयोग स्क्रम या कानबन (विकास) स्टैंडअप में रैखिक स्थितियों की रिपोर्टिंग की प्रक्रिया को बदल देता है।<ref>{{Cite web |title=Show Progress {{!}} Shape Up |url=https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill |access-date=2022-09-12 |website=basecamp.com}}</ref><ref>{{Cite web |title=Atlassian Marketplace |url=https://marketplace.atlassian.com/apps/1228986/shape-up-board-for-jira?hosting=cloud&tab=overview |access-date=2022-09-12 |website=marketplace.atlassian.com}}</ref>
इमारत के साथ आने वाली प्रोद्योगिकी अनिश्चितताओं को पहचानते हुए, चार्ट का उपयोग करके प्रगति को ट्रैक किया जाता है जो पहाड़ी के रूपक को देखता है, जिसे उपयुक्त रूप से पहाड़ी चार्ट नाम दिया गया है। अपहिल चरण वह है जहां निर्माता अभी भी स्वयं के दृष्टिकोण पर कार्य कर रहे हैं, जबकि डाउनहिल वह है जहां अज्ञात को समाप्त कर दिया गया है। निर्माता बेसकैंप या [[रुको (सॉफ्टवेयर)]] पर इंटरैक्टिव ऑनलाइन हिल चार्ट का उपयोग करके सक्रिय रूप से एवं एसिंक्रोनस रूप से स्व-रिपोर्ट प्रगति करते हैं, फोकस को अज्ञात या समाधान की गई समस्याओं पर ध्यान केंद्रित करते हैं या नहीं किया जाता है। हिल चार्ट का उपयोग जनसमूह (विकास) स्टैंडअप में रैखिक स्थितियों की रिपोर्टिंग की प्रक्रिया को परिवर्तित कर देता है।<ref>{{Cite web |title=Show Progress {{!}} Shape Up |url=https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill |access-date=2022-09-12 |website=basecamp.com}}</ref><ref>{{Cite web |title=Atlassian Marketplace |url=https://marketplace.atlassian.com/apps/1228986/shape-up-board-for-jira?hosting=cloud&tab=overview |access-date=2022-09-12 |website=marketplace.atlassian.com}}</ref>




=== उन्नत तरीके ===
=== उन्नत विधि ===


अन्य उच्च स्तरीय सॉफ्टवेयर परियोजना पद्धतियों में सम्मिलित  हैं:
अन्य उच्च स्तरीय सॉफ्टवेयर परियोजना पद्धतियों में सम्मिलित  हैं:


* [[व्यवहार-संचालित विकास]] एवं व्यवसाय प्रक्रिया प्रबंधन।<ref name="ieeeswbdd">{{Cite journal | doi=  10.1109/MS.2016.117 | title = Modeling Test Cases in BPMN for Behavior-Driven Development | journal = IEEE Software | volume = 33 | issue = 5 | pages =  15–21 | year = 2016 |author1=Lübke, Daniel  |author2=van Lessen, Tammo  | s2cid = 14539297 }}</ref>
* [[व्यवहार-संचालित विकास]] एवं व्यवसाय प्रक्रिया प्रबंधन हैं।<ref name="ieeeswbdd">{{Cite journal | doi=  10.1109/MS.2016.117 | title = Modeling Test Cases in BPMN for Behavior-Driven Development | journal = IEEE Software | volume = 33 | issue = 5 | pages =  15–21 | year = 2016 |author1=Lübke, Daniel  |author2=van Lessen, Tammo  | s2cid = 14539297 }}</ref>
* [[अराजकता मॉडल]] - मुख्य नियम हमेशा सबसे महत्वपूर्ण मुद्दे को पहले हल करता है।
* [[अराजकता मॉडल]]- मुख्य नियम सदैव सबसे महत्वपूर्ण विषय का समाधान करता है।
* [[इंक्रीमेंटल फंडिंग पद्धति]] - एक पुनरावृत्त दृष्टिकोण
* [[इंक्रीमेंटल फंडिंग पद्धति]]- पुनरावृत्त दृष्टिकोण
* लाइटवेट कार्यप्रणाली - विधियों के लिए एक सामान्य शब्द जिसमें केवल कुछ नियम एवं अभ्यास होते हैं
* लाइटवेट कार्यप्रणाली- विधियों के लिए सामान्य शब्द जिसमें केवल कुछ नियम एवं अभ्यास होते हैं
* संरचित प्रणाली विश्लेषण एवं डिजाइन विधि - जलप्रपात का एक विशिष्ट संस्करण
* संरचित प्रणाली विश्लेषण एवं डिजाइन विधि- जलप्रपात का विशिष्ट संस्करण हैI
* धीमी प्रोग्रामिंग, बड़े [[धीमी गति (संस्कृति)]] के हिस्से के रूप में, बिना (या न्यूनतम) समय के दबाव के सावधानीपूर्वक एवं  क्रमिक कार्य पर जोर देती है। धीमी प्रोग्रामिंग का उद्देश्य बग से बचना है एवं बहुत जल्दी रिलीज शेड्यूल करना है।
* शिथिल प्रोग्रामिंग, बड़े [[धीमी गति (संस्कृति)|शिथिल गति (संस्कृति)]] के भाग के रूप में, बिना (या न्यूनतम) समय के दबाव के सावधानीपूर्वक एवं  क्रमिक कार्य पर बल देती है। शिथिल प्रोग्रामिंग का उद्देश्य बग से बचना है एवं अतिशीघ्र सारणी करना है।
* वी-मॉडल (सॉफ्टवेयर विकास) - वॉटरफॉल मॉडल का विस्तार
* वी-मॉडल (सॉफ्टवेयर विकास)- वॉटरफॉल मॉडल का विस्तार हैI
* यूनिफाइड प्रोसेस (यूपी) [[एकीकृत मॉडलिंग भाषा]] (यूएमएल) पर आधारित एक पुनरावृत्त सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क है। यूपी सॉफ्टवेयर के विकास को चार चरणों में व्यवस्थित करता है, प्रत्येक में विकास के उस चरण में सॉफ्टवेयर के एक या अधिक निष्पादन योग्य पुनरावृत्तियों का समावेश होता है: स्थापना, विस्तार, निर्माण एवं दिशानिर्देश। यूपी कार्यान्वयन को सुविधाजनक बनाने के लिए कई उपकरण एवं उत्पाद मौजूद हैं। यूपी के अधिक लोकप्रिय संस्करणों में से एक तर्कसंगत [[एकीकृत प्रक्रिया]] (आरयूपी) है।
* यूनिफाइड प्रोसेस (यूपी) [[एकीकृत मॉडलिंग भाषा]] (यूएमएल) पर आधारित पुनरावृत्त सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क है। यूपी सॉफ्टवेयर के विकास को चार चरणों में व्यवस्थित करता है, प्रत्येक में विकास के उस चरण में सॉफ्टवेयर के अधिक निष्पादन योग्य पुनरावृत्तियों का समावेश होता है: स्थापना, विस्तार, निर्माण एवं दिशानिर्देश, यूपी कार्यान्वयन को सुविधाजनक बनाने के लिए कई उपकरण एवं उत्पाद उपस्थित हैं। यूपी के अधिक लोकप्रिय संस्करणों में से तर्कसंगत [[एकीकृत प्रक्रिया]] (आरयूपी) है।
*बिग बैंग कार्यप्रणाली - छोटी या अपरिभाषित परियोजनाओं के लिए एक दृष्टिकोण, आम तौर पर उच्च जोखिम के साथ बहुत कम या कोई योजना नहीं होती है।
*बिग बैंग कार्यप्रणाली छोटी या अपरिभाषित परियोजनाओं के लिए दृष्टिकोण, सामान्यतः उच्च विपत्ति के साथ अत्यधिक अल्प या कोई योजना नहीं होती है।


== प्रक्रिया मेटा-मॉडल ==
== प्रक्रिया मेटा-मॉडल ==


कुछ प्रक्रिया मॉडल किसी संगठन द्वारा अपनाई गई विशिष्ट प्रक्रिया के मूल्यांकन, तुलना एवं सुधार के लिए अमूर्त विवरण हैं।
कुछ प्रक्रिया मॉडल किसी संगठन द्वारा अपनाई गई विशिष्ट प्रक्रिया के मूल्यांकन, तुलना एवं सुधार के लिए अमूर्त विवरण हैं।


* ISO/IEC 12207 सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निगरानी की विधि का वर्णन करने वाला अंतर्राष्ट्रीय मानक है।
* ISO/IEC 12207 सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निरीक्षण की विधि का वर्णन करने वाला अंतर्राष्ट्रीय मानक है।
* [[[[क्षमता परिपक्वता मॉडल]] एकीकरण]] (CMMI) अग्रणी मॉडलों में से एक है एवं सर्वोत्तम प्रथाओं पर आधारित है। स्वतंत्र मूल्यांकन संगठनों को इस आधार पर ग्रेड देते हैं कि वे अपनी परिभाषित प्रक्रियाओं का कितनी अच्छी तरह पालन करते हैं, न कि उन प्रक्रियाओं या उत्पादित सॉफ़्टवेयर की गुणवत्ता पर। सीएमएमआई ने क्षमता परिपक्वता मॉडल को बदल दिया है।
* [[क्षमता परिपक्वता मॉडल]] एकीकरण (CMMI) अग्रणी मॉडलों में से है एवं सर्वोत्तम प्रथाओं पर आधारित है। स्वतंत्र मूल्यांकन संगठनों को इस आधार पर ग्रेड देते हैं कि वे अपनी परिभाषित प्रक्रियाओं का किस प्रकार से पालन करते हैं, न कि उन प्रक्रियाओं या उत्पादित सॉफ़्टवेयर की गुणवत्ता पर सीएमएमआई ने क्षमता परिपक्वता मॉडल को परिवर्तित कर दिया है।
* [[आईएसओ 9000]] एक उत्पाद के निर्माण के लिए औपचारिक रूप से संगठित प्रक्रिया के मानकों एवं प्रगति के प्रबंधन एवं निगरानी के उपाये का वर्णन करता है।चूँकि मानक मूल रूप से विनिर्माण क्षेत्र के लिए बनाया गया था, ISO 9000 मानकों को सॉफ्टवेयर विकास पर भी लागू किया गया है। सीएमएमआई की तरह, आईएसओ 9000 के साथ प्रमाणीकरण अंतिम परिणाम की गुणवत्ता की गारंटी नहीं देता है, केवल औपचारिक व्यावसायिक प्रक्रियाओं का पालन किया गया है।
* [[आईएसओ 9000]] उत्पाद के निर्माण के लिए औपचारिक रूप से संगठित प्रक्रिया के मानकों एवं प्रगति के प्रबंधन एवं निरीक्षण के उपाये का वर्णन करता है, चूँकि मानक मूल रूप से निर्माण क्षेत्र के लिए बनाया गया था, आईएसओ 9000 मानकों को सॉफ्टवेयर विकास पर भी प्रारम्भ किया गया है। सीएमएमआई के जैसे, आईएसओ 9000 के साथ प्रमाणीकरण अंतिम परिणाम की गुणवत्ता की आश्वाशन नहीं देता है, केवल औपचारिक व्यावसायिक प्रक्रियाओं का पालन किया गया है।
* ISO/IEC 15504 सूचना प्रौद्योगिकी—प्रक्रिया मूल्यांकन को सॉफ़्टवेयर प्रक्रिया सुधार क्षमता निर्धारण (SPICE) के रूप में भी जाना जाता है, यह सॉफ़्टवेयर प्रक्रियाओं के मूल्यांकन के लिए एक रूपरेखा है। इस मानक का उद्देश्य प्रक्रिया तुलना के लिए एक स्पष्ट मॉडल स्थापित करना है। SPICE का उपयोग CMMI की तरह ही किया जाता है। यह सॉफ्टवेयर विकास के प्रबंधन, नियंत्रण, मार्गदर्शन एवं निगरानी के लिए प्रक्रियाओं को मॉडल करता है। इस मॉडल का उपयोग यह मापने के लिए किया जाता है कि सॉफ्टवेयर विकास के समय एक विकास संगठन या परियोजना समहू वास्तव में क्या करती है। कमजोरियों की पहचान करने एवं सुधार लाने के लिए इस जानकारी का विश्लेषण किया जाता है। यह उन शक्तियों की भी पहचान करता है जिन्हें उस संगठन या समहू के लिए सामान्य अभ्यास में जारी रखा जा सकता है या एकीकृत किया जा सकता है।
* ISO/IEC 15504 सूचना प्रौद्योगिकी—प्रक्रिया मूल्यांकन को सॉफ़्टवेयर प्रक्रिया सुधार क्षमता निर्धारण (SPICE) के रूप में भी जाना जाता है, यह सॉफ़्टवेयर प्रक्रियाओं के मूल्यांकन के लिए रूपरेखा है। इस मानक का उद्देश्य प्रक्रिया तुलना के लिए स्पष्ट मॉडल स्थापित करना है। स्पाइस (SPICE) का उपयोग सीएमएमआई (CMMI) के जैसे ही किया जाता है। यह सॉफ्टवेयर विकास के प्रबंधन, नियंत्रण, मार्गदर्शन एवं निरीक्षण के लिए प्रक्रियाओं को मॉडल करता है। इस मॉडल का उपयोग यह मापने के लिए किया जाता है कि सॉफ्टवेयर विकास के समय विकास संगठन या परियोजना समहू वास्तव में क्या करती है। दुर्बलता की पहचान करने एवं सुधार लाने के लिए इस जानकारी का विश्लेषण किया जाता है। यह उन शक्तियों की भी पहचान करता है जिन्हें उस संगठन या समहू के लिए सामान्य अभ्यास में निरन्तर रखा जा सकता है या एकीकृत किया जा सकता है।
* ISO/IEC 24744 सॉफ्टवेयर इंजीनियरिंग-विकास पद्धतियों के लिए मेटामॉडल, सॉफ्टवेयर विकास पद्धतियों के लिए एक पावर टाइप-आधारित मेटामॉडल है।
* ISO/IEC 24744 सॉफ्टवेयर इंजीनियरिंग-विकास पद्धतियों के लिए मेटामॉडल, सॉफ्टवेयर विकास पद्धतियों के लिए पावर टाइप-आधारित मेटामॉडल है।
* ऑब्जेक्ट मैनेजमेंट ग्रुप द्वारा SPEM 2.0।
* ऑब्जेक्ट मैनेजमेंट ग्रुप द्वारा एसपीईएम (SPEM) 2.0 है।
* सॉफ्ट प्रणाली कार्यप्रणाली - प्रबंधन प्रक्रियाओं में सुधार के लिए एक सामान्य विधि।
* सॉफ्ट प्रणाली कार्यप्रणाली- प्रबंधन प्रक्रियाओं में सुधार के लिए सामान्य विधि है।
* [[विधि इंजीनियरिंग]] - सूचना प्रणाली प्रक्रियाओं में सुधार के लिए एक सामान्य विधि।
* [[विधि इंजीनियरिंग]]- सूचना प्रणाली प्रक्रियाओं में सुधार के लिए सामान्य विधि  है।
{{Further|Process patterns}}
{{Further|प्रक्रिया पैटर्न}}




== व्यवहार में ==
== व्यवहार में ==


[[Image:Three software development patterns mashed together.svg|thumb|420px|सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क पर लागू तीन बुनियादी दृष्टिकोण।]]इस तरह के कई प्रकार के ढांचे पिछले कुछ वर्षों में विकसित हुए हैं, जिनमें से प्रत्येक की अपनी मान्यता प्राप्त ताकत एवं कमजोरियां हैं। जरूरी नहीं कि एक सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क सभी प्रोजेक्ट्स के इस्तेमाल के लिए उपयुक्त हो। विभिन्न तकनीकी, संगठनात्मक, परियोजना एवं समहू के विचारों के आधार पर उपलब्ध प्रत्येक कार्यप्रणाली रूपरेखा विशिष्ट प्रकार की परियोजनाओं के लिए सबसे उपयुक्त है।<ref name="CMS08">Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). ''[http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf Selecting a development approach]''. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008.  Retrieved 27 Oct 2008.</ref>
[[Image:Three software development patterns mashed together.svg|thumb|420px|सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क पर प्रारम्भ तीन बुनियादी दृष्टिकोण।]]इस प्रकार की कई आकृति पूर्व के कुछ वर्षों में विकसित हुए हैं, जिनमें से प्रत्येक की अपनी मान्यता प्राप्त शक्ति एवं दुर्बलता हैं। आवश्यक नहीं कि सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क सभी प्रोजेक्ट्स के उपयोग के लिए उपयुक्त हो। विभिन्न प्रोद्योगिकी, संगठनात्मक, परियोजना एवं समहू के विचारों के आधार पर उपलब्ध प्रत्येक कार्यप्रणाली रूपरेखा विशिष्ट प्रकार की परियोजनाओं के लिए सबसे उपयुक्त है।<ref name="CMS08">Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). ''[http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf Selecting a development approach]''. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008.  Retrieved 27 Oct 2008.</ref>
सॉफ्टवेयर विकास संगठन विकास की प्रक्रिया को आसान बनाने के लिए प्रक्रिया पद्धतियों को लागू करते हैं। कभी-कभी, ठेकेदारों को नियोजित पद्धतियों की आवश्यकता हो सकती है, एक उदाहरण यू.एस. [[शस्त्र उद्योग]] है, जिसे अनुबंध प्राप्त करने के लिए प्रक्रिया मॉडल के आधार पर रेटिंग की आवश्यकता होती है। सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निगरानी की विधि का वर्णन करने के लिए अंतर्राष्ट्रीय मानक ISO/IEC 12207 है।
सॉफ्टवेयर विकास संगठन विकास की प्रक्रिया को सरल बनाने के लिए प्रक्रिया पद्धतियों को प्रारम्भ करते हैं। कभी-कभी, ठेकेदारों को नियोजित पद्धतियों की आवश्यकता हो सकती है, उदाहरण यू.एस. [[शस्त्र उद्योग]] है, जिसे अनुबंध प्राप्त करने के लिए प्रक्रिया मॉडल के आधार पर रेटिंग की आवश्यकता होती है। सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निरीक्षण की विधि का वर्णन करने के लिए अंतर्राष्ट्रीय मानक ISO/IEC 12207 है।


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


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


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


[[File:SLDC.jpg|thumb|सॉफ्टवेयर विकास जीवन चक्र (SDLC)]]
[[File:SLDC.jpg|thumb|सॉफ्टवेयर विकास जीवन चक्र (SDLC)]]
Line 208: Line 207:
* [[सॉफ्टवेयर विकास दर्शन की सूची]]
* [[सॉफ्टवेयर विकास दर्शन की सूची]]
* [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]]
* [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]]
* [[खुलना]]
* [[खुलना|ओपनअप]]
* परियोजना प्रबंधन
* परियोजना प्रबंधन
* सॉफ्टवेयर विकास
* सॉफ्टवेयर विकास
* [[सॉफ्टवेयर विकास प्रयास अनुमान]]
* [[सॉफ्टवेयर विकास प्रयास अनुमान]]
* [[सॉफ्टवेयर रिलीज जीवन चक्र]]
* [[सॉफ्टवेयर रिलीज जीवन चक्र|सॉफ्टवेयर प्रस्तावित जीवन चक्र]]
* टॉप-डाउन एवं बॉटम-अप डिज़ाइन #कंप्यूटर साइंस
* टॉप-डाउन एवं बॉटम-अप डिज़ाइन कंप्यूटर साइंस


== संदर्भ ==
== संदर्भ ==
Line 220: Line 219:


== बाहरी संबंध ==
== बाहरी संबंध ==
{{Commons category|Software development methodology}}
* [http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf Selecting a development approach] at cms.hhs.gov.
* [http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf Selecting a development approach] at cms.hhs.gov.
* Gerhard Fischer, [http://l3d.cs.colorado.edu/~gerhard/papers/isfst2001.pdf "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design"], 2001
* Gerhard Fischer, [http://l3d.cs.colorado.edu/~gerhard/papers/isfst2001.pdf "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design"], 2001
* [https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ Subway map of agile practices at Agile Alliance]
* [https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ Subway map of agile practices at Agile Alliance]
{{Software engineering}}
{{Authority control}}
{{Authority control}}


{{DEFAULTSORT:Software Development Methodology}}
{{DEFAULTSORT:Software Development Methodology}}
[[Category: सॉफ्टवेयर डेवलपमेंट प्रोसेस | सॉफ्टवेयर डेवलपमेंट प्रोसेस ]] [[Category: क्रियाविधि]] [[Category: सॉफ्टवेयर इंजीनियरिंग]]


[[Category: Machine Translated Page]]
[[Category:All Wikipedia articles written in American English|Software Development Methodology]]
[[Category:Created On 17/02/2023]]
[[Category:Articles with hatnote templates targeting a nonexistent page|Software Development Methodology]]
[[Category:Articles with invalid date parameter in template|Software Development Methodology]]
[[Category:CS1 English-language sources (en)]]
[[Category:Collapse templates|Software Development Methodology]]
[[Category:Commons category link is locally defined|Software Development Methodology]]
[[Category:Created On 17/02/2023|Software Development Methodology]]
[[Category:Lua-based templates|Software Development Methodology]]
[[Category:Machine Translated Page|Software Development Methodology]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists|Software Development Methodology]]
[[Category:Pages with script errors|Software Development Methodology]]
[[Category:Short description with empty Wikidata description|Software Development Methodology]]
[[Category:Sidebars with styles needing conversion|Software Development Methodology]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Translated in Hindi|Software Development Methodology]]
[[Category:Templates Vigyan Ready|Software Development Methodology]]
[[Category:Templates generating microformats|Software Development Methodology]]
[[Category:Templates that add a tracking category|Software Development Methodology]]
[[Category:Templates that are not mobile friendly|Software Development Methodology]]
[[Category:Templates that generate short descriptions|Software Development Methodology]]
[[Category:Templates using TemplateData|Software Development Methodology]]
[[Category:Use American English from April 2022|Software Development Methodology]]
[[Category:Wikipedia metatemplates|Software Development Methodology]]
[[Category:क्रियाविधि|Software Development Methodology]]
[[Category:सॉफ्टवेयर इंजीनियरिंग|Software Development Methodology]]
[[Category:सॉफ्टवेयर डेवलपमेंट प्रोसेस| सॉफ्टवेयर डेवलपमेंट प्रोसेस ]]

Latest revision as of 15:37, 27 October 2023


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

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

इतिहास

सॉफ्टवेयर विकास मेथडोलॉजी (जिसे SDM के रूप में भी जाना जाता है) फ्रेमवर्क 1960 के दशक तक सामने नहीं आया था। इलियट (2004) के अनुसार, प्रणाली विकास जीवन चक्र (SDLC) को सूचना प्रणाली के निर्माण के लिए अत्यधिक प्राचीन औपचारिक कार्यप्रणाली आकृति मानी जा सकती है। एसडीएलसी का मुख्य विचार सूचना प्रणाली के विकास को अत्यधिक सुविचारित, संरचित एवं व्यवस्थित उपाये से आगे बढ़ाने के लिए किया गया है, जिसमें जीवन चक्र के प्रत्येक चरण की आवश्यकता होती है, विचार के प्रारम्भ से लेकर अंतिम प्रणाली की डिलीवरी तक होने के लिए जटिलता से एवं क्रमिक रूप से किया गया I[2] प्रारम्भ किए जा रहे आकृति के संदर्भ में 1960 के दशक में इस कार्य प्रणाली आकृति का मुख्य लक्ष्य बड़े स्तर के व्यापारिक समूहों के युग में बड़े स्तर पर कार्यात्मक व्यापार प्रणाली विकसित करना था। सूचना प्रणाली की गतिविधियाँ भारी डाटा प्रासेसिंग एवं अभिकलन दिनचर्या के चारों ओर पर्यटन करती हैं।[2]

कार्यप्रणालियाँ, प्रक्रियाएँ, एवं आकृति विशिष्ट निर्देशात्मक पदों से लिए जाते हैं जिनका उपयोग किसी संगठन द्वारा दिन-प्रतिदिन के कार्य में किया जा सकता है,परिवर्तनशील आकृति के लिए जिसका उपयोग संगठन किसी विशिष्ट परियोजना की आवश्यकताओं के अनुरूप पदों के प्रचलन समूह को उत्पन्न करने के लिए करता है या समूह कुछ स्तिथियों में, प्रायोजक या सुरक्षा संगठन प्रपत्र का आधिकारिक समूह वितरित करता है जो प्रक्रिया का वर्णन करता है। विशिष्ट उदाहरणों में सम्मिलित हैं:

1970 के दशक
1980 के दशक
  • 1980 के पश्चात से संरचित प्रणाली विश्लेषण एवं डिजाइन पद्धति (एसएसएडीएम) है।
  • सूचना आवश्यकता विश्लेषण / सॉफ्ट प्रणाली पद्धति है।
1990 के दशक
-2000

2010 के दशक

यह उल्लेखनीय है कि 1994 में डीएसडीएम (DSDM) के पश्चात से, आरयूपी (RUP) को त्यागकर उपरोक्त सूची की सभी कार्यप्रणालियाँ निपुण रही हैं, फिर भी कई संगठन, विशेष रूप से सरकारें, अभी भी प्री-एजाइल प्रक्रियाओं (प्रायःजलप्रपात या समान) का उपयोग करती हैं। सॉफ़्टवेयर प्रक्रिया एवं सॉफ़्टवेयर गुणवत्ता का परस्पर गहन संबंध है; व्यवहार में कुछ अनपेक्षित सापेक्ष एवं प्रभाव देखे गए हैं [3] इनमें से अन्य सॉफ्टवेयर विकास प्रोसेस ओपन स्रोत सॉफ्टवेयर में स्थापित किया गया है। किसी कंपनी की सीमाओं के अंदर ज्ञात एवं स्थापित प्रक्रियाओं के इन सर्वोत्तम अभ्यासों को अपनाने को आंतरिक स्रोत कहा जाता है।

प्रोटोटाइपिंग

सॉफ़्टवेयर प्रोटोटाइपिंग प्रोटोटाइप बनाने के विषय में है, अर्थात विकसित किए जा रहे सॉफ़्टवेयर प्रोग्राम के अर्द्धनिर्मित संस्करण मूल सिद्धांत हैं:[1]

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

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

उपाये

प्रवीण विकास

Main article: प्रवीण सॉफ्टवेयर विकास

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

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

अस्थिर मॉडल में निम्नलिखित सॉफ्टवेयर विकास प्रक्रियाएं भी सम्मिलित हैं:[4]

निरंतर एकीकरण

Main article: निरंतर एकीकरण

निरंतर एकीकरण सभी डेवलपर कार्यशील प्रतियों को ट्रंक (सॉफ़्टवेयर) में दिन में कई बार व्याधि करने का अभ्यास है।[5] ग्रेडी बूच ने प्रथम बार बूच विधि में सीआई का नाम दिया एवं प्रस्तावित किया,[6] चूँकि उन्होंने दिन में कई बार एकीकरण करने का प्रतिनिधित्व नहीं किया। एक्सट्रीम प्रोग्रामिंग (XP) ने सीआई (CI) की अवधारणा को अपनाया एवं प्रतिदिन एकीकृत करने का प्रतिनिधित्व किया I

वृद्धिशील विकास

Main article: पुनरावृत्त एवं वृद्धिशील विकास

रैखिक एवं पुनरावृत्त प्रणालियों के विकास के उपाये के संयोजन के लिए विभिन्न उपाये स्वीकार्य किये हैं, जिनमें से प्रत्येक का प्राथमिक उद्देश्य परियोजना को छोटे खंडों में विभक्त करके निहित परियोजना विपत्ति को अर्घ्य करना एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करना है।

वृद्धिशील विकास के तीन मुख्य रूप हैं:[1]

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

तीव्र अनुप्रयोग विकास

Main article: रैपिड अनुप्रयोग का विकास
तीव्र आवेदन विकास (आरएडी) मॉडल

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

तीव्र विकास प्रक्रिया संरचित प्रौद्योगिकी का उपयोग करके प्रारंभिक डेटा मॉडल एवं व्यवसाय प्रक्रिया मॉडल के विकास के साथ प्रारम्भ होती है। अगले चरण में, प्रोटोटाइप का उपयोग करके आवश्यकताओं को सत्यापित किया जाता है, अंततः डेटा एवं प्रक्रिया मॉडल को परिष्कृत करने के लिए, इन चरणों को पुनरावृत्त रूप से दोहराया जाता है; नई प्रणालियों के निर्माण के लिए उपयोग की जाने वाली संयुक्त व्यावसायिक आवश्यकताओं एवं प्रौद्योगिकी डिजाइन विवरण में आगे के विकास के परिणाम है।[7]

इस शब्द का प्रथम बार 1991 में जेम्स मार्टिन (लेखक) द्वारा प्रारम्भ की गई सॉफ्टवेयर विकास प्रक्रिया का वर्णन करने के लिए उपयोग किया गया था। व्हिटेन (2003) के अनुसार, यह विभिन्न संरचित विश्लेषण एवं डिजाइन प्रविधि का विलय है, विशेष रूप से डेटा-संचालित सूचना प्रौद्योगिकी इंजीनियरिंग, प्रोटोटाइप के साथ सॉफ्टवेयर प्रणाली विकास में तीव्र गति के लिए प्रविधि [7]तीव्र अनुप्रयोग विकास के मूल सिद्धांत हैं:[1]

  • मुख्य उद्देश्य अपेक्षाकृत कम निवेश वित्त पर उच्च गुणवत्ता वाली प्रणाली का तीव्र गति से विकास एवं वितरण करना है।
  • परियोजना को छोटे खंडों में करके एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके निहित परियोजना विपत्ति को अल्प करने का प्रयास हैं।
  • मुख्य रूप से पुनरावृत्त प्रोटोटाइप (विकास के किसी भी चरण में), सक्रिय उपयोगकर्ता भागीदारी एवं कम्प्यूटरीकृत विकास उपकरण के माध्यम से उच्च गुणवत्ता वाली प्रणालियों का निर्माण करना है। इन उपकरणों में ग्राफिकल यूज़र इंटरफ़ेस (GUI) निर्माता, कंप्यूटर एडेड सॉफ्टवेयर इंजीनियरिंग (CASE) टूल्स, डेटाबेस प्रबंधन प्रणाली (DBMS), चौथी पीढ़ी की प्रोग्रामिंग भाषा, कोड जनरेटर एवं ऑब्जेक्ट-ओरिएंटेड प्रविधि सम्मिलित हो सकती हैं।
  • व्यवसाय की आवश्यकता को पूर्ण करने पर मुख्य बल दिया जाता है, जबकि प्रौद्योगिकी या इंजीनियरिंग उत्कृष्टता का महत्व अल्प होता है।
  • परियोजना नियंत्रण में विकास को प्राथमिकता देना एवं डिलीवरी की समय सीमा या "टाइमबॉक्स" को परिभाषित करना सम्मिलित है। यदि परियोजना विफल होने लगती है, तो समय-सीमा में उपयुक्त होने के लिए आवश्यकताओं को अल्प करने पर बल दिया जाता है, न कि समय सीमा बढ़ाने में बल देता है।
  • सामान्यतः संयुक्त अनुप्रयोग डिज़ाइन (JAD) सम्मिलित होता है, जहाँ उपयोगकर्ता या तो संरचित कार्यशालाओं में सर्वसम्मति निर्माण के माध्यम से, या इलेक्ट्रॉनिक रूप से वार्तालाप के माध्यम से प्रणाली की रूपरेखा में गंभीर रूप से सम्मिलित होते हैं।
  • सक्रिय उपयोगकर्ता भागीदारी अनिवार्य है।
  • प्रोटोटाइप के विपरीत, क्रमिक रूप से उत्पादन सॉफ्टवेयर का उत्पादन करता है।
  • भविष्य के विकास एवं सुरक्षा की सुविधा के लिए आवश्यक प्रपत्र प्रस्तुत करता है।
  • इस आकृति में मानक प्रणाली विश्लेषण एवं डिजाइन विधियों को उपयुक्त किया जा सकता है।

जलप्रपात विकास

Main article: जलप्रपात मॉडल
वाटरफॉल मॉडल में प्रदर्शित सॉफ्टवेयर विकास प्रक्रिया की गतिविधियां। इस प्रक्रिया का प्रतिनिधित्व करने के लिए कई अन्य मॉडल हैं।

जलप्रपात मॉडल क्रमिक विकास का दृष्टिकोण है, जिसमें विकास को कई चरणों के माध्यम से निरंतर नीचे की ओर सामान्यतः (जलप्रपात के जैसे) बहने के रूप में देखा जाता हैI

विधि का प्रथम औपचारिक विवरण प्रायः विंस्टन डब्ल्यू रॉयस द्वारा प्रकाशित लेख के रूप में उद्धृत किया जाता हैI[8] 1970 में, चूँकि रॉयस ने इस लेख में जलप्रपात शब्द का प्रयोग नहीं किया। रॉयस ने इस मॉडल को त्रुटिपूर्ण, अन्य-कार्यशील मॉडल के उदाहरण के रूप में प्रस्तुत किया।[9] मूल सिद्धांत हैं:[1]

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

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

सर्पिल विकास

सर्पिल मॉडल (बोहम, 1988)
Main article: सर्पिल मॉडल

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

  • केन्द्रित विपत्ति मूल्यांकन पर है एवं परियोजना को छोटे खंडों में करके एवं विकास प्रक्रिया के समय अधिक सरलता से परिवर्तन प्रदान करके परियोजना विपत्ति को अल्प करने के साथ-साथ विपत्ति का मूल्यांकन करने एवं सम्पूर्ण जीवन चक्र में परियोजना की निरंतरता पर विचार करने का सुयोग प्रदान करता है। .
  • प्रत्येक चक्र में उत्पाद के प्रत्येक भाग के लिए एवं विस्तार के प्रत्येक स्तर के लिए चरणों के क्रम के माध्यम से प्रगति सम्मिलित है, समग्र अवधारणा-संचालन प्रपत्रो से लेकर प्रत्येक व्यक्तिगत कार्यक्रम की कोडिंग तक है।[10]
  • सर्पिल के चारों ओर प्रत्येक यात्रा चार मूल चतुर्भुजों को ज्ञात करती है: (1) पुनरावृत्ति के उद्देश्यों, विकल्पों एवं बाधाओं को निर्धारित करती है, एवं (2) विकल्पों का मूल्यांकन करती है; विपत्तियो की पहचानें एवं निवारण करें; (3) पुनरावृत्ति से डिलिवरेबल्स का विकास एवं सत्यापन; एवं (4) अगले पुनरावृत्ति की योजना बनाएं।[11]
  • प्रत्येक चक्र को हितधारकों एवं उनकी विजय की स्थिति की पहचान के साथ प्रारम्भ करें, एवं प्रत्येक चक्र को समीक्षा एवं प्रतिबद्धता के साथ समाप्त करें।[12]


आकार

आकार 2018 में बेसकैंप (कंपनी) द्वारा प्रस्तुत किया गया, सॉफ्टवेयर विकास का दृष्टिकोण है। यह सिद्धांतों एवं प्रौद्योगिकीयो का समहू है जिसे बेसकैंप ने आंतरिक रूप से विकसित किया है जिससे बिना किसी स्पष्ट अंत के परियोजनाओं की समस्या को दूर किया जा सके। इसका प्राथमिक लक्षित दर्शक दूरस्थ समहू हैं। वॉटरफॉल मॉडल, एजाइल सॉफ्टवेयर विकास या स्क्रम (सॉफ्टवेयर विकास) के विपरीत आकार का कोई अनुमान एवं वेग ट्रैकिंग, बैकलॉग या स्प्रिंट नहीं है। इसके अनुसार, उन अवधारणाओं को एपेटाइट, सट्टेबाजी एवं चक्रों से परिवर्तित कर दिया जाता है। 2022 तक, बेसकैंप के अतिरिक्त, आकार को अपनाने वाले उल्लेखनीय संगठनों में उपयोगकर्ता ध्वनि (UserVoice) एवं ब्लॉक (Block) सम्मिलित हैं।[13][14]


चक्र

परीक्षणों एवं त्रुटियों के माध्यम से, बेसकैंप ने ज्ञात किया कि आदर्श चक्र की अवधि 6 सप्ताह है। यह 6 सप्ताह की अवधि सार्थक विशेषता बनाने के लिए अत्यधिक बड़ी है एवं अत्यावश्यकता की भावना उत्पन्न करने के लिए अभी भी अत्यधिक अल्प है।

आकार देना

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


एपेटाइट

जिस प्रकार से आकार यह निर्धारित करता है कि किसी परियोजना के लिए कितना समय आवंटित किया गया है, वह अन्य पद्धतियों के विपरीत है। आकार एपेटाइट के साथ प्रारम्भ होता है (उदाहरण के लिए, 6 सप्ताह) एवं समाधान डिजाइन के साथ समाप्त होता है जिसे इस बाधा के अंदर वितरित किया जा सकता है। परियोजना के निर्माता के लिए एपेटाइट कठिन समय सीमा बन जाती है।[17]


भवन

आकार दो-ट्रैक प्रणाली है जहां आकृति एवं निर्माता समानांतर में कार्य करते हैं। वर्तमान चक्र में जो कार्य आकार ले रहा है, वह भविष्य के चक्र में निर्माण करने के लिए डिजाइनरों एवं इंजीनियरों को दिया जा सकता है।

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


उन्नत विधि

अन्य उच्च स्तरीय सॉफ्टवेयर परियोजना पद्धतियों में सम्मिलित हैं:

  • व्यवहार-संचालित विकास एवं व्यवसाय प्रक्रिया प्रबंधन हैं।[20]
  • अराजकता मॉडल- मुख्य नियम सदैव सबसे महत्वपूर्ण विषय का समाधान करता है।
  • इंक्रीमेंटल फंडिंग पद्धति- पुनरावृत्त दृष्टिकोण
  • लाइटवेट कार्यप्रणाली- विधियों के लिए सामान्य शब्द जिसमें केवल कुछ नियम एवं अभ्यास होते हैं
  • संरचित प्रणाली विश्लेषण एवं डिजाइन विधि- जलप्रपात का विशिष्ट संस्करण हैI
  • शिथिल प्रोग्रामिंग, बड़े शिथिल गति (संस्कृति) के भाग के रूप में, बिना (या न्यूनतम) समय के दबाव के सावधानीपूर्वक एवं क्रमिक कार्य पर बल देती है। शिथिल प्रोग्रामिंग का उद्देश्य बग से बचना है एवं अतिशीघ्र सारणी करना है।
  • वी-मॉडल (सॉफ्टवेयर विकास)- वॉटरफॉल मॉडल का विस्तार हैI
  • यूनिफाइड प्रोसेस (यूपी) एकीकृत मॉडलिंग भाषा (यूएमएल) पर आधारित पुनरावृत्त सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क है। यूपी सॉफ्टवेयर के विकास को चार चरणों में व्यवस्थित करता है, प्रत्येक में विकास के उस चरण में सॉफ्टवेयर के अधिक निष्पादन योग्य पुनरावृत्तियों का समावेश होता है: स्थापना, विस्तार, निर्माण एवं दिशानिर्देश, यूपी कार्यान्वयन को सुविधाजनक बनाने के लिए कई उपकरण एवं उत्पाद उपस्थित हैं। यूपी के अधिक लोकप्रिय संस्करणों में से तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) है।
  • बिग बैंग कार्यप्रणाली छोटी या अपरिभाषित परियोजनाओं के लिए दृष्टिकोण, सामान्यतः उच्च विपत्ति के साथ अत्यधिक अल्प या कोई योजना नहीं होती है।

प्रक्रिया मेटा-मॉडल

कुछ प्रक्रिया मॉडल किसी संगठन द्वारा अपनाई गई विशिष्ट प्रक्रिया के मूल्यांकन, तुलना एवं सुधार के लिए अमूर्त विवरण हैं।

  • ISO/IEC 12207 सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निरीक्षण की विधि का वर्णन करने वाला अंतर्राष्ट्रीय मानक है।
  • क्षमता परिपक्वता मॉडल एकीकरण (CMMI) अग्रणी मॉडलों में से है एवं सर्वोत्तम प्रथाओं पर आधारित है। स्वतंत्र मूल्यांकन संगठनों को इस आधार पर ग्रेड देते हैं कि वे अपनी परिभाषित प्रक्रियाओं का किस प्रकार से पालन करते हैं, न कि उन प्रक्रियाओं या उत्पादित सॉफ़्टवेयर की गुणवत्ता पर सीएमएमआई ने क्षमता परिपक्वता मॉडल को परिवर्तित कर दिया है।
  • आईएसओ 9000 उत्पाद के निर्माण के लिए औपचारिक रूप से संगठित प्रक्रिया के मानकों एवं प्रगति के प्रबंधन एवं निरीक्षण के उपाये का वर्णन करता है, चूँकि मानक मूल रूप से निर्माण क्षेत्र के लिए बनाया गया था, आईएसओ 9000 मानकों को सॉफ्टवेयर विकास पर भी प्रारम्भ किया गया है। सीएमएमआई के जैसे, आईएसओ 9000 के साथ प्रमाणीकरण अंतिम परिणाम की गुणवत्ता की आश्वाशन नहीं देता है, केवल औपचारिक व्यावसायिक प्रक्रियाओं का पालन किया गया है।
  • ISO/IEC 15504 सूचना प्रौद्योगिकी—प्रक्रिया मूल्यांकन को सॉफ़्टवेयर प्रक्रिया सुधार क्षमता निर्धारण (SPICE) के रूप में भी जाना जाता है, यह सॉफ़्टवेयर प्रक्रियाओं के मूल्यांकन के लिए रूपरेखा है। इस मानक का उद्देश्य प्रक्रिया तुलना के लिए स्पष्ट मॉडल स्थापित करना है। स्पाइस (SPICE) का उपयोग सीएमएमआई (CMMI) के जैसे ही किया जाता है। यह सॉफ्टवेयर विकास के प्रबंधन, नियंत्रण, मार्गदर्शन एवं निरीक्षण के लिए प्रक्रियाओं को मॉडल करता है। इस मॉडल का उपयोग यह मापने के लिए किया जाता है कि सॉफ्टवेयर विकास के समय विकास संगठन या परियोजना समहू वास्तव में क्या करती है। दुर्बलता की पहचान करने एवं सुधार लाने के लिए इस जानकारी का विश्लेषण किया जाता है। यह उन शक्तियों की भी पहचान करता है जिन्हें उस संगठन या समहू के लिए सामान्य अभ्यास में निरन्तर रखा जा सकता है या एकीकृत किया जा सकता है।
  • ISO/IEC 24744 सॉफ्टवेयर इंजीनियरिंग-विकास पद्धतियों के लिए मेटामॉडल, सॉफ्टवेयर विकास पद्धतियों के लिए पावर टाइप-आधारित मेटामॉडल है।
  • ऑब्जेक्ट मैनेजमेंट ग्रुप द्वारा एसपीईएम (SPEM) 2.0 है।
  • सॉफ्ट प्रणाली कार्यप्रणाली- प्रबंधन प्रक्रियाओं में सुधार के लिए सामान्य विधि है।
  • विधि इंजीनियरिंग- सूचना प्रणाली प्रक्रियाओं में सुधार के लिए सामान्य विधि है।
Further information: प्रक्रिया पैटर्न


व्यवहार में

सॉफ्टवेयर विकास मेथडोलॉजी फ्रेमवर्क पर प्रारम्भ तीन बुनियादी दृष्टिकोण।

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

सॉफ्टवेयर विकास संगठन विकास की प्रक्रिया को सरल बनाने के लिए प्रक्रिया पद्धतियों को प्रारम्भ करते हैं। कभी-कभी, ठेकेदारों को नियोजित पद्धतियों की आवश्यकता हो सकती है, उदाहरण यू.एस. शस्त्र उद्योग है, जिसे अनुबंध प्राप्त करने के लिए प्रक्रिया मॉडल के आधार पर रेटिंग की आवश्यकता होती है। सॉफ्टवेयर के जीवन चक्र के चयन, कार्यान्वयन एवं निरीक्षण की विधि का वर्णन करने के लिए अंतर्राष्ट्रीय मानक ISO/IEC 12207 है।

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

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

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

सॉफ्टवेयर विकास जीवन चक्र (SDLC)

यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Selecting a development approach. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008. Retrieved 27 Oct 2008.
  2. ↑ 2.0 2.1 Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.
  3. ↑ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.
  4. ↑ "software development process". 19 August 2020.
  5. ↑ "Continuous Integration".
  6. ↑ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Retrieved 18 August 2014.
  7. ↑ 7.0 7.1 Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6th edition. ISBN 0-256-19906-X.
  8. ↑ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
  9. ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
  10. ↑ Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986
  11. ↑ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130
  12. ↑ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.
  13. ↑ "Foreword by Jason Fried | Shape Up". basecamp.com. Retrieved 2022-09-11.
  14. ↑ "Is Shape Up just a nice theory?". Curious Lab (in English). Retrieved 2022-09-12.
  15. ↑ "Principles of Shaping | Shape Up". basecamp.com. Retrieved 2022-09-11.
  16. ↑ "Bets, Not Backlogs | Shape Up". basecamp.com. Retrieved 2022-09-11.
  17. ↑ "Hand Over Responsibility | Shape Up". basecamp.com. Retrieved 2022-09-11.
  18. ↑ "Show Progress | Shape Up". basecamp.com. Retrieved 2022-09-12.
  19. ↑ "Atlassian Marketplace". marketplace.atlassian.com. Retrieved 2022-09-12.
  20. ↑ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117. S2CID 14539297.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_विकास_प्रक्रिया&oldid=271227’