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

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

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

इतिहास

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

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

1970 के दशक

1969 से संरचित प्रोग्रामिंग
कैप जेमिनी एसडीएम (Cap Gemini SDM), मूल रूप से पांडाता (PANDATA) से, प्रथम अंग्रेजी अनुवाद 1974 में प्रकाशित हुआ था। एसएडीएम (SDM) का अर्थ प्रणाली विकास मेथडोलॉजी है

1980 के दशक

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

1990 के दशक

वस्तु-उन्मुख प्रोग्रामिंग (OOP) 1960 के दशक के प्रारम्भ में विकसित हुई एवं 1990 के दशक के मध्य में प्रमुख प्रोग्रामिंग दृष्टिकोण बन गई।
रैपिड एप्लीकेशन विकास (आरएडी), 1991 से
गतिशील प्रणाली विकास मेथड (DSDM), 1994 से
जनसमूह (सॉफ्टवेयर विकास), 1995 से
समूह सॉफ्टवेयर प्रक्रिया, 1998 से
विवेकशील एकीकृत प्रक्रिया (RUP), 1998 से आईबीएम (IBM) द्वारा अनुरक्षित
एक्सट्रीम प्रोग्रामिंग, 1999 से

-2000

रैशनल यूनीफाइड प्रोसेस (AUP) स्कॉट एंबलर द्वारा 2005 से अनुरक्षित
अनुशासित निपुण डिलीवरी (डीएडी) एयूपी का स्थान लेती है

2010 के दशक

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

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

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

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

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

उपाये

प्रवीण विकास

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

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

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

गतिशील प्रणाली विकास मेथड (DSDM)
कानबन (विकास)
जनसमूह (विकास)
क्रिस्टल
अटर्न
क्षीणकाय सॉफ्टवेयर विकास

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

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

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

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

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

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

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

तीव्र आवेदन विकास (आरएडी) मॉडल

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

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

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

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

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

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

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

आवश्यकताओं का विश्लेषण जिसके परिणामस्वरूप एक सॉफ्टवेयर आवश्यकता विनिर्देशन होता है
सॉफ्टवेर डिज़ाइन
कंप्यूटर प्रोग्रामिंग
सॉफ़्टवेयर परीक्षण
प्रणाली एकीकरण
सॉफ़्टवेयर परिनियोजन (या स्थापना (कंप्यूटर प्रोग्राम))
सॉफ्टवेयर रखरखाव

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

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

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

सर्पिल विकास

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

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

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

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

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

व्यवहार में

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

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

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

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

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

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

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

यह भी देखें

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

संदर्भ

↑ ^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.0 ^2.1 Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.
↑ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.
↑ "software development process". 19 August 2020.
↑ "Continuous Integration".
↑ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Retrieved 18 August 2014.
↑ ^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.
↑ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
↑ Conrad Weisert, Waterfall methodology: there's no such thing!
↑ Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986
↑ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130
↑ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.
↑ "Foreword by Jason Fried | Shape Up". basecamp.com. Retrieved 2022-09-11.
↑ "Is Shape Up just a nice theory?". Curious Lab (in English). Retrieved 2022-09-12.
↑ "Principles of Shaping | Shape Up". basecamp.com. Retrieved 2022-09-11.
↑ "Bets, Not Backlogs | Shape Up". basecamp.com. Retrieved 2022-09-11.
↑ "Hand Over Responsibility | Shape Up". basecamp.com. Retrieved 2022-09-11.
↑ "Show Progress | Shape Up". basecamp.com. Retrieved 2022-09-12.
↑ "Atlassian Marketplace". marketplace.atlassian.com. Retrieved 2022-09-12.
↑ 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.

बाहरी संबंध

Selecting a development approach at cms.hhs.gov.
Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design", 2001
Subway map of agile practices at Agile Alliance

[CMS08-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.

[Ell04-2] 2.0 ^2.1 Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.

[ieeesw-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.

[CI0-5] "Continuous Integration".

[6] Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Retrieved 18 August 2014.

[WBD04-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!

[BB86-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

[RT-BB86-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.

[ieeeswbdd-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.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

Anonymous

Search

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

Namespaces

More

Page actions

Contents

इतिहास

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