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

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

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

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

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

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


 * 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 के दशक


 * स्केल्ड एजाइल फ्रेमवर्क (SAFe)
 * बड़े पैमाने पर जमघट (LeSS)
 * DevOps

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

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

मूल सिद्धांत हैं:


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

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

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

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

चंचल मॉडल में निम्नलिखित सॉफ्टवेयर विकास प्रक्रियाएं भी सम्मिलित हैं:
 * डायनेमिक सिस्टम डेवलपमेंट मेथड (DSDM)
 * कानबन (विकास)
 * स्क्रम (विकास)
 * क्रिस्टल
 * अटर्न
 * दुबला सॉफ्टवेयर विकास

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

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

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


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

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

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

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


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

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


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

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


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

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

सर्पिल विकास


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

मूल सिद्धांत हैं:


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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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



यह भी देखें

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

बाहरी संबंध

 * 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