सॉफ्टवेयर विकास प्रक्रिया जटिल है; किसी कंपनी के अंदर किसी भी अन्य परियोजना की तरह, इसे सावधानीपूर्वक नियोजित और प्रबंधित करने की आवश्यकता होती है। कंपनियां अपने व्यवसाय के लगभग किसी भी पहलू में परियोजना प्रबंधन रणनीतियों को लागू करती हैं। सॉफ़्टवेयर विकास जैसी जटिल चीज़ की योजना बनाने और प्रबंधित करने के लिए हमारे पास रणनीतियाँ क्यों नहीं होनी चाहिए?
एक विकास टीम जो आगे के काम की योजना के बिना विकास प्रक्रिया में कूद जाती है, देरी, अधिक बजट और विफलता का सामना करने की अधिक संभावना होती है। इस कारण से, सॉफ्टवेयर विकास क्षेत्र में सॉफ्टवेयर विकास जीवन चक्र रणनीतियाँ अत्यधिक महत्वपूर्ण हैं। इस लेख में, हम एक सॉफ्टवेयर विकास जीवन चक्र पर चर्चा करने जा रहे हैं, जिसमें सॉफ्टवेयर विकास प्रक्रिया के सभी चरणों को तोड़ दिया गया है।
सॉफ्टवेयर विकास जीवन चक्र क्या है?
एक सॉफ्टवेयर विकास जीवन चक्र सॉफ्टवेयर विकास प्रक्रिया में शामिल सभी चरणों का टूटना है। प्रत्येक कंपनी या विकास टीम अपना स्वयं का कस्टम सॉफ़्टवेयर विकास जीवन चक्र बना सकती है जिसे वे उन सभी विकास परियोजनाओं के लिए दोहराते हैं जिन पर वे काम करते हैं। हालाँकि, सभी सॉफ्टवेयर विकास जीवन चक्र रणनीतियों के लिए कुछ बुनियादी सिद्धांत सामान्य हैं, जो जानने योग्य हैं। उदाहरण के लिए, प्रत्येक सॉफ़्टवेयर विकास जीवन चक्र मॉडल निम्न पथ का भिन्नरूप है:
- आवश्यकता विश्लेषण
- योजना चरण
- उत्पाद डिजाइन चरण
- कोडिंग चरण
- परीक्षण चरण
- सत्यापन चरण
- परिनियोजन चरण
- रखरखाव का चरण
जब किसी व्यवसाय ने अपना दोहराए जाने योग्य सिस्टम विकास जीवन चक्र बनाया है, तो वह इसे किसी भी सॉफ़्टवेयर प्रोजेक्ट के लिए तैनात कर सकता है जिसमें वे शामिल हैं। इस तरह की नींव रखने से एक विकास टीम को अधिक गति और निरंतरता के साथ काम करने की अनुमति मिलती है, समयरेखा और लागतों के बारे में अधिक जागरूक रहें, गलतियों से बचें , और अल्पावधि में मुद्दों को रोकें; सॉफ्टवेयर विकास जीवन चक्र सॉफ्टवेयर विकास प्रक्रिया को अनुकूलित करता है जिससे यह अधिक कुशल, तेज और लागत प्रभावी हो जाता है।
सॉफ्टवेयर विकास जीवन चक्र कैसे काम करता है?
सॉफ़्टवेयर प्रोजेक्ट जीवन चक्र पूरे सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट को चरणों में तोड़ देता है। भले ही डेवलपर्स जानते हैं कि प्रत्येक चरण अन्य सभी से जुड़ा हुआ है, वे उनमें से प्रत्येक को अलग से प्रबंधित कर सकते हैं। प्रत्येक सॉफ़्टवेयर विकास जीवनचक्र चरण में लक्ष्य, कार्य, बजट, दस्तावेज़ीकरण, असाइन की गई टीम और समय सीमा होती है।
इसके अलावा, प्रत्येक चरण में एक आउटपुट, एक ठोस परिणाम होना चाहिए। उदाहरण के लिए, नियोजन चरण का आउटपुट नियोजन प्रक्रिया से संबंधित प्रलेखन होना चाहिए और जिस योजना की रूपरेखा तैयार की गई है, कोडिंग चरण का आउटपुट कोड है।
जैसा कि हमने उल्लेख किया है, चरणों की कोई निर्धारित संख्या नहीं है, लेकिन प्रत्येक कंपनी या टीम अपने संसाधनों, कौशल, आदतों और अपेक्षाओं के आधार पर अपना स्वयं का SDLC बना सकती है। हालांकि, कुछ चरणों को हर SDLC का हिस्सा होना चाहिए। क्रम बदल सकता है, लेकिन हम निम्नलिखित पैराग्राफ में जिन चरणों को तोड़ रहे हैं, वे आपके सिस्टम विकास जीवन चक्र से गायब नहीं होने चाहिए।
SDLC के चरण
आवश्यकता विश्लेषण
जैसा कि प्रत्येक परियोजना प्रबंधक हमें सिखा सकता है, प्रत्येक परियोजना का पहला चरण, एक सॉफ्टवेयर परियोजना सहित, एक ऐसा चरण होना चाहिए जिसमें टीम अपने परियोजना की आवश्यकताओं को समझे। इस स्तर पर, आपको निम्नलिखित को परिभाषित करना चाहिए:
- लक्ष्य
- व्यापार के लिए लाभ
- आवश्यक संसाधन (मानव संसाधन, बजट, सॉफ्टवेयर उपकरण)
- समय सीमा
इस चरण में न केवल डेवलपर्स शामिल हैं: उदाहरण के लिए, इसमें व्यवसाय विश्लेषण से कुछ मदद की भी आवश्यकता हो सकती है, जो उन पहलुओं को उजागर कर सकता है जो डेवलपर्स को कम करके आंका जा सकता है, जैसे लागत लाभ विश्लेषण और कंपनी के लिए मूल्य।
यह तब भी है जब विकास दल यह तय करता है कि वे किस तरह के विकास के दृष्टिकोण को अपनाएंगे: क्या वे हर एक लाइन को कोड करेंगे? वे किन प्रोग्रामिंग भाषाओं का उपयोग करने जा रहे हैं? क्या वे AppMaster जैसे no-code टूल का उपयोग करेंगे? और अगर वे AppMaster जैसे टूल का उपयोग करते हैं, तो क्या वे स्वचालित रूप से जेनरेट किए गए कोड को संपादित करेंगे?
इन सवालों के जवाब अभी बहुत शुरुआती चरण में दिए जाने की जरूरत है।
आवश्यकता विश्लेषण चरण का आउटपुट सॉफ़्टवेयर आवश्यकता विनिर्देश दस्तावेज़ है जिसमें आगामी परियोजना के सभी विनिर्देशों (सॉफ़्टवेयर, हार्डवेयर, नेटवर्क और सुरक्षा) को शामिल करने की आवश्यकता है, निश्चित रूप से, परियोजना अनुसूची, लागत अनुमान और प्रत्येक के अलावा आवश्यकता विश्लेषण चरण के दौरान विस्तार से चर्चा की गई और तैयार की गई।
योजना चरण
सॉफ़्टवेयर के डिज़ाइन, कोड और विकास पर आगे बढ़ने से पहले, यह महत्वपूर्ण है कि परियोजना प्रबंधक, असाइन की गई टीम के साथ मिलकर, विकास प्रक्रिया के प्रमुख पहलुओं की रूपरेखा तैयार करे। इस चरण के दौरान, विकास दल टूट जाते हैं:
- सॉफ्टवेयर आर्किटेक्चर: डेटाबेस, ऑपरेटिंग सिस्टम, प्रोग्रामिंग लैंग्वेज, एपीआई एस, फ्रेमवर्क
- यूजर इंटरफेस डिजाइन
- बुनियादी ढांचे की आवश्यकताएं
- सुरक्षा ( SSL एन्क्रिप्शन और प्रमाणपत्र, पासवर्ड सुरक्षा, और बहुत कुछ)
जैसे आवश्यकता विश्लेषण चरण के लिए आउटपुट एक दस्तावेज़ है जिसे सॉफ़्टवेयर आवश्यकताएँ विनिर्देश दस्तावेज़ कहा जाता है, नियोजन चरण का आउटपुट दस्तावेज़ीकरण है जो उतना ही महत्वपूर्ण है। इसे अक्सर डिज़ाइन दस्तावेज़ विशिष्टता या DDS कहा जाता है। इसमें वे सभी जानकारी शामिल होनी चाहिए जो डेवलपर्स को सॉफ़्टवेयर उत्पाद बनाने के लिए चाहिए।
डिजाइन चरण में
कोडिंग (या वैकल्पिक पद्धतियों) में कूदने से पहले, डेवलपर या डेवलपर्स की टीम को अपने सॉफ़्टवेयर उत्पाद को सावधानी से डिजाइन करना चाहिए। निम्नलिखित चरण का अनुकूलन करना महत्वपूर्ण है। डिजाइन चरण के दौरान, आपको निम्नलिखित को इंगित करने की आवश्यकता होगी:
- यूआई : उपयोगकर्ता प्लेटफॉर्म के साथ कैसे इंटरैक्ट करेगा;
- प्रोग्रामिंग : आप कौन सा दृष्टिकोण अपनाएंगे (कोड या विज़ुअल प्रोग्रामिंग , कौन सी प्रोग्रामिंग भाषा, कौन सा no-code टूल)
- संचार : सॉफ्टवेयर अन्य संपत्तियों के साथ कैसे इंटरैक्ट करेगा
- प्लेटफार्म : कौन से प्लेटफॉर्म सॉफ्टवेयर को होस्ट करने जा रहे हैं
- सुरक्षा : आप अपने सॉफ़्टवेयर को सुरक्षित करने के लिए कौन से उपाय करने जा रहे हैं?
कोडिंग चरण
कोडिंग चरण वह है जहां सॉफ्टवेयर डेवलपर वास्तव में सॉफ्टवेयर बनाना शुरू करते हैं। यदि उन्होंने सबसे पारंपरिक दृष्टिकोण चुना है, तो यहीं से उन्होंने कोड लिखना शुरू किया। यदि उन्होंने एक अलग दृष्टिकोण चुना है, जैसे low-code या no-code, तो यह वह जगह है जहां वे पसंद के no-code प्लेटफॉर्म का उपयोग करना शुरू करते हैं, उदाहरण के लिए, AppMaster, और वे अपने सॉफ़्टवेयर को डिज़ाइन करने के लिए पूर्व-निर्मित सॉफ़्टवेयर ब्लॉक को असेंबल करना शुरू करते हैं। उत्पाद।
आप आसानी से समझ सकते हैं कि अगर टीम पिछले सभी चरणों से गुजर चुकी है तो कोडिंग चरण को कैसे अनुकूलित किया जा सकता है। कोडिंग कार्य, या no-code प्लेटफॉर्म का उपयोग अब अधिक सीधा है: टीम का प्रत्येक सदस्य जानता है कि क्या करना है, क्या सीमाएं हैं, और लक्ष्य क्या हैं। कोडिंग चरण तब तक पूरा नहीं हुआ है जब तक कि यह आवश्यक आउटपुट प्रदान नहीं करता है जो परीक्षण योग्य और पूरी तरह कार्यात्मक सॉफ्टवेयर है।
परीक्षण चरण
पिछले विकास चरण में प्रदान किए गए सॉफ़्टवेयर को अब परीक्षण चरण में परीक्षण करने की आवश्यकता है। परीक्षण उसी टीम द्वारा चलाए जा सकते हैं जो सॉफ़्टवेयर पर काम करती है या एक अलग परीक्षण टीम। परीक्षण दल को मुख्य विकासशील दल से अलग करना कब बेहतर होता है? जब भी आप पारंपरिक मैनुअल कोडिंग दृष्टिकोण को लागू करते हैं, परीक्षण चरण अधिक जटिल और लंबा होता है, और इसके लिए आमतौर पर नए सिरे से आंखों की आवश्यकता होती है: इस मामले में, यह एक अलग परीक्षण टीम के लिए बेहतर है।
यदि आप इसके बजाय no-code दृष्टिकोण चुनते हैं, तो सॉफ़्टवेयर परीक्षण चरण तेज और आसान है। ऐसा इसलिए है क्योंकि डेवलपर मैन्युअल रूप से कोड नहीं लिखता है और इसलिए:
- एक ओर, कोड स्वचालित रूप से उत्पन्न होता है और त्रुटियों के अधीन कम होता है। इसलिए, सॉफ्टवेयर परीक्षण चरण तेज है;
- दूसरी ओर, डेवलपर ने कोड नहीं लिखा है, इसलिए उनके पास अतिरिक्त परीक्षण टीम या व्यक्ति की सहायता के बिना सॉफ़्टवेयर परीक्षण चरण से गुजरने के लिए नई आँखें हैं।
सत्यापन चरण
इस विकास चरण में, सभी सिस्टम परीक्षण पूरा होने के बाद, सॉफ्टवेयर को अंतिम रूप दिया जा सकता है। सत्यापन चरण अत्यंत महत्वपूर्ण है क्योंकि यहां जो अंतिम रूप दिया गया है वह जल्द ही जनता के लिए महसूस किया जाएगा या कंपनी के भीतर तैनात किया जाएगा।
परिनियोजन चरण
परिनियोजन चरण तब होता है जब सॉफ़्टवेयर को चयनित प्लेटफ़ॉर्म पर लागू किया जाता है। उदाहरण के लिए, यदि आप अपनी कंपनी की आंतरिक प्रक्रियाओं के लिए सॉफ़्टवेयर विकसित करते हैं, तो यह तब होता है जब आप अपने सहकर्मियों को अपना सॉफ़्टवेयर प्रोजेक्ट प्रदान करते हैं और वे इसका उपयोग करना प्रारंभ कर सकते हैं। यदि आप एक मोबाइल ऐप विकसित करते हैं, तो आप इसे परिनियोजन चरण में चुनिंदा ऐप स्टोर पर लॉन्च करते हैं।
रखरखाव का चरण
सॉफ़्टवेयर के जारी या तैनात किए जाने पर विकास प्रक्रिया समाप्त नहीं होती है। जैसा कि आप पहले से ही जानते होंगे, सभी सॉफ़्टवेयर को रखरखाव की आवश्यकता होती है। यह एक ऐसा तथ्य है जो तब तक रहता है जब तक आपका सॉफ़्टवेयर उपयोग किया जाता है: आपको इसे लगातार अपडेट करने, किसी भी संभावित समस्या को ठीक करने और इसकी संभावनाओं के शीर्ष पर बनाए रखने की आवश्यकता है।
अस्वीकरण
हमने सॉफ़्टवेयर विकास जीवन चक्र को फ़नल-समान पथ के रूप में वर्णित किया है: प्रत्येक विकास चरण दूसरे के बाद आता है और अगला विकासशील चरण तब तक प्रारंभ नहीं हो सकता जब तक कि पिछला चरण पूरा नहीं हो जाता। हालाँकि, हमें यह स्पष्ट करना चाहिए कि परियोजना जीवन चक्र को सख्ती से रेखीय नहीं होना चाहिए। इसके विपरीत, आप अक्सर विकास प्रक्रिया के दौरान सुधार करने और परियोजना को अनुकूलित करने के लिए खुद को पिछले चरणों में वापस जाते हुए पाएंगे। जितना अधिक आप काम करते हैं और जीवन चक्र दृष्टिकोण का उपयोग करके सॉफ़्टवेयर बनाते हैं, उतना ही कम आपको अपने पिछले चरणों को ठीक करने के लिए वापस जाने की आवश्यकता होगी।
SDLC मॉडल और कार्यप्रणालियाँ समझाई गईं
जबकि विकास के चरण समान रहते हैं, उनका क्रम या महत्व भिन्न हो सकता है। उनके प्रति दृष्टिकोण भी भिन्न हो सकता है। जब हम सॉफ़्टवेयर विकास जीवन चक्र की व्याख्या करने के विभिन्न तरीकों के बारे में बात करते हैं, तो हम प्रोजेक्ट जीवन चक्र मॉडल के बारे में बात करते हैं। यह पैराग्राफ सबसे आम सॉफ्टवेयर इंजीनियरिंग जीवन चक्र मॉडल पर चर्चा करेगा।
झरना मॉडल
जलप्रपात मॉडल सबसे सरल मॉडल है जिसका उपयोग आप SDLC में कर सकते हैं। इसे रैखिक मॉडल के रूप में भी जाना जाता है और इसके लिए आवश्यक है कि आप विकास के अगले चरण पर तब तक नहीं जा सकते जब तक आप जिस पर काम कर रहे हैं वह पूरा नहीं हो जाता है और आवश्यक आउटपुट प्रदान नहीं करता है। चरणों का क्रम पिछले पैराग्राफ में वर्णित है और शायद ही कभी बदलता है।
पुनरावृत्त वृद्धिशील मॉडल
इस मॉडल के साथ, बड़े सॉफ्टवेयर इंजीनियरिंग प्रोजेक्ट को छोटे-छोटे टुकड़ों में तोड़ दिया जाता है। उदाहरण के लिए, प्रत्येक सुविधा को अलग से निपटाया जा सकता है। जब परियोजना के विभिन्न भागों की पहचान की जाती है, तो प्रत्येक व्यक्ति SDLC के सभी विभिन्न चरणों से गुजरता है।
चुस्त कार्यप्रणाली
इन दिनों सबसे अधिक उपयोग किए जाने वाले मॉडलों में से एक एजाइल मॉडल है । फुर्तीली कार्यप्रणाली को पुनरावृत्त वृद्धिशील मॉडल की भिन्नता के रूप में माना जा सकता है: एजाइल मॉडल एक बड़े सॉफ्टवेयर इंजीनियरिंग प्रोजेक्ट को छोटे ब्लॉकों में तोड़ देता है, और प्रत्येक ब्लॉक को पिछले एक के पूरा होने के बाद विकसित किया जाता है।
हालाँकि, एजाइल कार्यप्रणाली वाली परियोजना की लगातार ग्राहक या विकासशील सॉफ़्टवेयर सेवा की आवश्यकता वाले किसी भी व्यक्ति द्वारा समीक्षा की जाती है। कार्य को टुकड़ों में विभाजित किया जाता है जिसे स्प्रिंट कहा जाता है। प्रत्येक स्प्रिंट के अंत में, कार्य की समीक्षा की जाती है और, जबकि आप निम्नलिखित स्प्रिंट पर जा सकते हैं, आप पिछले स्प्रिंट पर प्रतिक्रिया भी प्राप्त कर सकते हैं और आवश्यकता पड़ने पर संभावित पहलुओं को सुधार या सुधार सकते हैं। एजाइल मॉडल में, विकास और परीक्षण के बीच निरंतर संपर्क होता है। यह किसी भी अन्य मॉडल की तुलना में अधिक लचीला है और इसीलिए सॉफ्टवेयर विकास उद्योग में इसका व्यापक रूप से उपयोग किया जाता है।
SDLC के लाभ
बेहतर दक्षता
जैसा कि किसी अन्य प्रकार की परियोजना के साथ होता है, प्रक्रिया के दौरान पालन करने के लिए खुद को और अपनी टीम को योजना बनाने और प्रदान करने से हमेशा दक्षता और उत्पादकता में वृद्धि होती है। कार्य अधिक कुशल है क्योंकि आपको प्रत्येक चरण में निम्नलिखित चाल पर निर्णय लेने की आवश्यकता नहीं है; इसमें शामिल सभी लोग समान कार्यप्रवाह साझा करते हैं और जानते हैं कि क्या करना है। दक्षता में सुधार, टीम और ग्राहकों के साथ संचार भी आसान बना दिया गया है।
बढ़ाया सहयोग
क्योंकि संचार में सुधार हुआ है, विभिन्न टीमों या टीम के सदस्यों के बीच सहयोग भी बढ़ा है। जब, उदाहरण के लिए, आवश्यकता विश्लेषण टीम और विकासशील टीम अलग और अलग होती है, दोनों के बीच संचार, और एक चरण से दूसरे चरण में जाने को सरल बना दिया जाता है क्योंकि जो टीम दूसरे स्थान पर आती है उसे पिछले से संबंधित एक विस्तृत दस्तावेज़ प्रदान किया जाता है मंच।
उच्च सफलता दर
पालन करने के लिए एक स्पष्ट मार्ग के साथ, कार्य को अनुकूलित और बढ़ाया जाता है। इसके परिणामस्वरूप आपकी विकास परियोजनाओं की सफलता की संभावना बढ़ जाती है।
कमतर लागतें
क्योंकि शुरुआती चरणों में विस्तृत लागत-लाभ विश्लेषण की आवश्यकता होती है, प्रत्येक चरण को एक बजट दिया जाता है, और क्योंकि गलतियाँ कम हो जाती हैं (और इसलिए समय भी कम हो जाता है) जब आप एक SDLC तैनात करते हैं तो विकास प्रक्रिया की लागत अनिवार्य रूप से कम हो जाती है।
